Notices by Râu Cao ⚡ (raucao@kosmos.social), page 3

@evan Ultimately, it would be amazing if they could all be made interoperable, of course, but I doubt that everyone will ever agree on the same algos and other details. But still, everyone would need the same MLS primitive functions for their Web clients, so that's why the library/API question is interesting to me.

@evan Thanks! Yeah, it seems to me like a high-quality library would solve the same problem, and we'd have to polyfill one anyway, for browsers that don't support MLS primitives natively yet. In the long run, it could increase performance by not having to download that code, of course.

I asked, because I had just looked into the library situation a couple of days ago, and it seems like there's nothing available in TS/JS at the moment:

https://kosmos.social/@raucao/113192277991674267

@evan I just read your blog post, where it says "One thing I learned is that Mozilla is working on an MLS implementation in the browser". Did they/you mean that as they're working on a Web API for MLS, which they want to implement in Firefox first? 🤔

@silverpill @feld My point is that architectural basics *that* important should be on the roadmap of e.g. the Mastodon company, and prominent AP authors and proponents should be calling for them.

@feld Not an unlikely scenario, I agree. This is a problem space where it makes even more sense to look at e.g. Nostr for solutions.

At the same time, Nostr could learn a thing or two from federated systems to improve performance and UX. I always said it'll somewhat resemble a federated system eventually, for various reasons.

@feld That is, if both of us run our own XMPP server, and they connect with TLS, then the two of us sending unencrypted messages is more private than NIP-04.

@feld Client support for proper private messages is actually terrible on Nostr right now, because the thing that all clients support literally leaks all your metadata to everyone. But yeah, at least the keys have to be managed already.

@feld My hope is that the keys they have to introduce for E2EE DMs will basically make it a no-brainer to use them for signing posts as well.

@feld I thought it would be obvious to everyone how important client-side signing and portable objects are. But I hear mostly crickets when it comes to those FEPs and the problem in general.

It would seem that a lot of people actually like control over other people's stuff. As an admin, I absolutely hate that our users have to depend on us to even enable follower migration in the first place, while content migration is not even a thing.

@feld

@feld I'm failing to find where that central point of control is in the protocol, other than just the main instance censoring specific PDSs or domains. Which part of the system is run by a single entity that could censor my own instance?

@feld That can't be the end goal of the protocol design. Are you saying their goal is to never be able to self-host the full stack of services? Since you can use your own domain, how can you not just point to whatever you want for all of them?

@feld How could they enforce that for your own instance? Wouldn't that just be a restriction for their own web UI and official client builds?

@bumi

@lain @feld Don't worry, scrote. There are plenty of 'tards out there living really kick-ass lives. My first wife was 'tarded. She's a pilot now.

@feld @lain Idiocracy has to be realized fully now, otherwise the last few years are just sunk cost.

@lain Smiley face!

There's a website containing questions for the German citizenship test (for practice), and in the middle of that long list of hypocritical half-truths, I found this absolute gem of a "correct" answer:

@lain Another Japan-Korea Annexation Treaty?

https://en.wikipedia.org/wiki/Japan%E2%80%93Korea_Treaty_of_1910

If you're happy about *this* guy winning an election, you should probably contemplate your tribalist reflexes:

https://www.declassifieduk.org/keir-starmer-joined-secretive-cia-linked-group-while-serving-in-corbyns-shadow-cabinet/