@elle

also, what do you mean by corporate takeover?

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

(thanks @mkljczk)

@silverpill @elle >endless meetings

the E2EE TG appears to be a weird one that already presented something useful

@mkljczk @elle What did they present?

@silverpill @mkljczk minutes are posted to this repo: https://github.com/swicg/meetings

I think the ones from today will be posted in the near future. basically, @benpate + @mayel discussed their impls + doing a demo. all of us discussed metadata leakage mitigations + alternatives for the AP actor that will be the MLS auth service (AS). plus some meta conversations about using alt spaces to GitHub like activitypub.space to host spec discussion

fwiw, I like the idea of using FEP process to dev e2ee

We have two working prototypes, and a very clear idea of the gaps between the current spec and what we'd need to do this at scale.

It's not really reflected on Github at the moment, but we're going to try to "clean our room before mom gets home" and make it represent the current state of the project.

My goal is to close those gaps, and make a clear protocol for Mastodon to implement in 2027.

@silverpill @mkljczk @elle

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

how else do you suggest we develop an E2EE protocol for the fediverse? 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.

also, what do you mean by corporate takeover?

@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.

Online meetings are tedious, especially as the group gets larger. But everyone I've interacted with in the E2EE group (and a few others) has had only the best intentions for the Fediverse.

So, I hope you won't avoid them just because they're "corporate".

Tedious? Well, you've got a point there.

It if would help, I'm happy to discuss all of the plans and discussions out here. That's actually how elle ended up attending this morning's meeting :)

@silverpill @elle

@benpate @elle The observed output and the very existence of SWICG is completely at odds with what I do and what I value about Fediverse, no matter what the intentions may be.

@silverpill @benpate yeah, fwiw they are the main standards body, though. i know you know that, just saying that there is value in trying to work together with them, since w/e protocol they land on will likely be adopted by Mastodon, and thus a very significant portion of the fediverse.

not saying an independent alternative impl is valueless, i'm serious about working on it, only that we're still at a stage in fedi-e2ee dev to meaningfully influence the protocol in a positive direction

@elle It's not the main standards body, it didn't even exist before 2022-23 https://lists.w3.org/Archives/Public/public-swicg/

At that time, we already had FEP process and 12 years of fediverse development behind us.

Do you see many fedi developers in these github working groups? I don't. And there is a good reason for that.

@silverpill that's interesting information I wasn't privvy to, thanks for changing that.

no, I don't see many fedi devs there, outside of Embassy + Bonfire folks. I'm also not a fan of the use of GitHub, and brought up moving to an alternative git forge. we reached a middle-ground of linking to discussions on activitypub.space, but I still don't like the continued presence of FOSS on a platform like GitHub that is actively hostile to its existence.

@elle It's good that you brought it up. I think fediverse standards should be discussed on Fediverse.