[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Tomas Härdin]

lör 2024-04-27 klockan 12:53 +0200 skrev Michael Niedermayer:
> On Thu, Apr 25, 2024 at 12:26:00PM +0200, Tomas Härdin wrote:
> > tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer:
> > > On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote:
> > > > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer:
> > > > 
> > > > > * ffchat
> > > > >     (expand into realtime chat / zoom) this would
> > > > >     bring in more users and developers, and we basically have
> > > > > almost
> > > > >     all parts for it already but some people where against it
> > > > 
> > > > You mean inventing a new chat protocol? If so then please
> > > > don't. We
> > > 
> > > If theres an existing protocol that serves the purpose then
> > > theres no
> > > need to invent a new one
> > > 
> > > I think at a minimum it should have "secure and private by
> > > default
> > > and always"
> > > (there are many solutions already when one is willing to give up
> > > security/privacy)
> > 
> > "Security" and "privacy" are relative terms.
> 
> yes, more security and privacy is better

Not always. More security is typically more work. For example TOFU
(trust on first use) is easy but you should really compare
fingerprints. The latter is more work however.

I've worked with helping people who have a need or even a legal
obligation to secure their chats, such as journalists. This is non-
trivial. Have you done the necessary research on this?

> > If you want end-to-end encryption in a federated system then
> > XMPP+OMEMO
> > is the way to go. Or Matrix I guess, but it isn't standardized last
> > time I checked.
> > 
> > If you want metadata resistance then Briar is the way to go. It's a
> > peer-to-peer store-and-forward network that tunnels all its
> > internet
> > traffic through Tor, and also supports synchronizing messages over
> > WiFi
> > Direct and Bluetooth.
> > 
> > There's also GNUnet and its associated protocols like psyc.
> > 
> > Short of using some complicated thing involving data diodes you're
> > not
> > likely to do better than what's already out there. And nothing
> > beats
> > not using computers at all.
> 
> sure, i agree, we should use existing protocols whenever one exists
> for a purpose already ...
> 
> libavformat supports, RTP, RTSP, MMS, HLS, RTMP and probably more
> we support audio, video, data and text packets/streams
> 
> So adding support for some more secure/private protocols is
> within the scope of libavformat.

I'm curious what protocols you have in mind, assuming we're still
talking multimedia. Taking XMPP as an example, multimedia attachments
are handled via HTTP upload, meaning playback only depends on HTTP(S)
support. I expect most XMPP clients already leverage libav* for
playback

> And it would allow all multimedia players to use these more secure
> means of communicating.

Why do media players need chat functionality? Should we implement email
while we're at it?

> As well as writing dedicated secure chat applications on
> top of libavformat.

I can imagine many things more pleasant than writing a chat system on
top of lavf, such as eating sand. Or even worse, having to take such
systems into consideration when attempting to refactor lavf..

> This would bring in more users and developers

Outreach would likely be more effective, and far less work

/Tomas