mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

582
comptes actifs

#webrtc

2 messages2 participants0 message aujourd’hui

Here comes Movim 0.31, codename Kameny ✨

With this exciting new release you'll be able to share simultaneously your screen and webcam when calling your friends 👀, switch quickly between your one-to-one chats and chatrooms ⚡, add your pronoun in your profile 🏳️‍🌈...

Checkout our release note to discover all the other new features of this version 🗒️

mov.im/community/pubsub.movim.

Thanks again to @nlnet for their support on the video-conference features ❤️

#xmpp#movim#release

So, dann schauen wir mal, ob Europa in der Lage ist, die DS-GVO anzuwenden und die Verantwortlichen der irischen Datenschutzkommission (Data Protection Commission, DPC) die cojones haben, Meta mit der Höchststrafe für Datenschutzverstöße zu beglücken.
localmess.github.io/
Was denkst du?
#webRTC #meta #yandex #dsgvo

localmess.github.ioCovert Web-to-App Tracking via Localhost on Android
Suite du fil

Both #Yandex and #Meta used obfuscation techniques to hide that the traffic occured and/or that the apps were listening to these requests:

➡️ Meta traffic was using #WebRTC, which does not show up in the browser's developer tools
➡️ Yandex traffic looked non-local
➡️ Yandex apps started listening only after several days

BTW: Apparently, Meta stopped doing this yesterday. But they probably still have the mapping DB.
All the details by the researchers here.
localmess.github.io/

localmess.github.ioCovert Web-to-App Tracking via Localhost on Android

FilePizza • Your files, delivered.
Peer-to-peer file transfers in your browser.

Using WebRTC, FilePizza eliminates the initial upload step required by other web-based file sharing services. Because data is never stored in an intermediary server, the transfer is fast, private, and secure.

🍕 file.pizza

file.pizzaFilePizza • Your files, delivered.Peer-to-peer file transfers in your web browser.
#filetransfer#webrtc#p2p

I like p2p communication with webRTC better and better. not having a server in between which stores messages, but only sending messages (directly or in the form of a queue) when both peers are online. writing a message queue is my next step in my #KaiOS app #webRTC #KaiOS github.com/strukturart/flop

GitHubGitHub - strukturart/flop: KaiOS p2p messenger appKaiOS p2p messenger app. Contribute to strukturart/flop development by creating an account on GitHub.

I'm trying to do live #streaming with some friends. I can't quite figure out #obs.

RTP is the ideal protocol (low latency, simple to multiplex on a server), but OBS doesn't support it.

OBS supports RTMP, but that's high latency, which isn't suitable since I'll be expecting to interact with my audience.

The last choice is WHIP/WebRTC, But #VLC doesn't support #WebRTC, so I don't even know what to use client size.

Any suggestions? Is anyone doing live streams with open source software?

After taking a closer look at #XMPP clients for the #linux desktop, there's this frustrating "tie" for finding a favorite.

#Dino, which is likeable for being able to do video and audio calls, only has limited support for multi-user chat (complete with fancy moderation tools). These audio and video calls it can do are AMD64-only at this time.

#Gajim, which is likeable for being able to do multi-user chat well (with great moderation tools), alas, can't do audio and video calls to the other XMPP clients (like, say, #Conversations, as they use a newer #WebRTC-based method now).

So there's this strange situation where one is tempted to use both at the same time.

My takeaway is that #Conversations for #Android is the only xmpp client that I would possibly and carefully recommend to family and friends at this time, as it can cover all of the above. (#Monal on #iOS/#MacOS only has "partial" support for Multi-user chat, BTW.)

Yes I'm aware of the existence of Snikket, Quicksy, and Prav. No need to chime in on those.

id like to share some details about how my app works so you can discover/give me feedback on my app. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify.

github.com/positive-intentions

positive-intentions.com/blog/i

im not an expert on #cyberSecurity. im sure there are many gaps in my knowlege in this domain.

using #javascript, i initially created a fairly basic #chatApp using using #peerjs to create #encrypted #webrtc #connections. this was then easily enhanced by exchanging additional #encryption #keys from #cryptography functions built into browsers (#webcrypto api) to add a redundent layer of encryption. a #diffieHelman key #exchange is done over #webrtc (which can be considered #secure when exchanged over public channels) to create #serverless #p2p #authentication.

- i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have #openedSource my #cryptography module. its basically a thin wrapper around vanilla cryptography functions of a #browser (webcrypto api).

- another concern for my kind of app (#PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for #selfhosting. selhosting this app has some unique features. unlike many other #selfhosted #projects, this app can be hosted on #githubPages (instructions are provided in the readme). im also working towards having better support for running the index.html directly without a static server.

- to prevent things like browser extensions, the app uses strict #CSP headers to prevent #unauthorised code from running. #selfhosting users should take note of this when setting up their own instance.

- i received feedback the #Signal/#Simplex protocol is great. completely undertsandable and agree, but wonder if im reducing the #complexity by working with #webrtc. while it has its many flaws, i think risks can be reasonable mitigated if the #cryptography functions are implemented correctly. (all data out is #encrypted and all data in is #decrypted on-the-fly)

- the key detail that makes this approach unique, is because as a #webapp, unlike other solutions, users have a choice of using any #device/#os/#browser. while a webapp can have nuanced #vulnerabilities, i think by #openSourcing and providing instructions for #selfhosting and instructions to #build for various #platforms, it can provide a reasonable level of #security.

i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the #frontend and the peerjs-server to be #hosted #independently, im on track for creating a #chatSystem with the "fewest moving parts". i hope you will agree this is true #p2p and i hope i can use this as a step towards true #privacy and #security. #security might be further improved by using a trusted #VPN.

while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find #bestPractices for the functionalities i want to achieve. in particular #security practices to use when using #p2p technology.

(note: this app is an #unstable, #experiment, #proofOfConcept and not ready to replace any other app or service. It's far from finished and provided for #testing and #demo purposes only. This post is to get #feedback on the progress to determine if i'm going in the right direction for a secure chat app)

GitHubGitHub - positive-intentions/chat: Decentralized chatDecentralized chat. Contribute to positive-intentions/chat development by creating an account on GitHub.