@elle

also, what do you mean by corporate takeover?

This picture: https://pl.fediverse.pl/objects/2fee01c3-d3d2-4443-9dd5-6d4ec84580c4

(thanks @mkljczk)

@elle

fwiw the gate is pretty easy to open, but does require signing a CLA.

It's not that simple. But it might appear easy if you don't inconvenience them too much, and jump through all the hoops https://github.com/swicg/charters/blob/main/stage-process.md

how else do you suggest we develop an E2EE protocol for the fediverse?

In the same way as everything up until this moment has been developed. Somebody just needs to do it.

If the result is good, others will copy it.

>you mention in your FEP that you are giving up on it for a proper E2EE impl. genuinely asking b/c I'm interested in getting E2EE, hopefully interoperable with widest number of clients possible.

Not giving up - I want to explore a more advanced encryption scheme. I think the basics are not going to change too much.

also, what do you mean by corporate takeover?

A lot of things.

@silverpill @mkljczk I can't load that for some reason... it redirects me to this link: https://pl.fediverse.pl/@/posts/AmWtsGl9UNnu7VAzqq

@elle @mkljczk It returns 404. Maybe the author deleted the post.

@silverpill @elle no, i locked down my instance a bit too much

@silverpill

With NIKE (Non-Interactive-Key-Exchange) one sided forward secrecy is the best you can get. AFAIK the fediverse model strongly favors 0-RTT messaging, so I think the FEP as designed is close to ideal, as something simple that fits the use-case.

I will be the first to admit that my knowledge in the protocol is severely lacking, but if you have cryptography related questions, please let me know.

@greyarea

>Non-Interactive-Key-Exchange

I think interactive key exchange is fine too. Activities and requests are often sent back and forth between fediverse servers. The most canonical example is probably the Follow activity to which remote server responds with Accept.

>but if you have cryptography related questions, please let me know.

Thank you. I will surely have a lot of questions in the future.

@silverpill yeah, that staging process is definitely more bureaucratic and formal than "write a FEP, implement it, respond to feedback". but plenty of non-corpo entities have a similar level of bureaucracy, especially in the standards space. idk, am relatively new to the space, so if there is some history or context I'm missing, I'm open to new info.

I'm also down to work together with you on writing an FEP together, and/or writing up some of my ideas about how an MLS-based protocol could work

@elle

bureaucracy

Bureaucracy is not necessary, the FEP process proves that. However, I can tolerate bureaucracy if people who are running the standardization process are qualified for the job. E.g. I wouldn't mind if fediverse was represented by an alliance of Mastodon, PeerTube and Lemmy developers.

I'm also down to work together with you on writing an FEP together, and/or writing up some of my ideas about how an MLS-based protocol could work

That would be great, although I am not sure if MLS is our best option. It is too complicated.

@silverpill I agree MLS is complicated, however it's the best standard for doing E2EE, and it's been vetted by a number of trustworthy professional cryptographers. whatever alternative is chosen would need to meet at least that level of scrutiny. also, if we want to be interoperable with what SWICG is working on, it would need to be MLS based, as that's what they've chosen.

if going in a totally different direction, I'd be interested to hear what you have in mind

@elle If nobody can implement it, it's a bad standard.

I didn't say that we should go in a totally different direction. But how ActivityPub E2EE will look like remains an open question.

@silverpill absolutely, E2EE is still WIP. I don't think MLS is so complicated that no one can implement it. in a lot of cases, implementers shouldn't have to touch the low-level MLS implementation. OpenMLS exists for Rust, and ts-mls exists for TS/JS. the OpenMLS can be wrapped by anything that can talk to a C FFI. at least how I understand the Embassy/Bonfire impls, they are using those MLS primitives to build up the protocol.

In addition to MLS, I want to explore:

- DMLS variants
- BeeKEM
- Autocrypt

@jupiter_rowland @elle I am also concerned about mobile and desktop clients. The developers may not want to add Rust compiler to their toolchains.