Notices by Blake Leonard (blake@infosec.town)

Okay so I more or less know that WhatsApp, Matrix, and XMPP are all planning to integrate with MIMI. I wonder if @delta is also trying to brainstorm ways to integrate their chatmail distribution with MIMI, once the specs are finalized?

@delta The Matrix Foundation is helping to specify it (there are two "employees" there credited in the "core" specification), as are members of the XMPP Software Foundation. The specification is also designed specifically with WhatsApp in mind as well, though I'm not sure they have any commitment to it (instead, it is likely that it will be pushed on them by legal force).
The "more or less" is to say, they haven't specifically come out and said it but their actions and investment in the protocol indicate that, once it's finalized or near finalized enough for use, we'll start seeing MSP(s) and XEP(s) specifying how those protocols would interact with and implement MIMI.

I'd expect Element (and Synapse) would be relatively quick to implement it based on their very evident interest, but because XMPP is so fragmented they'll lag behind as always. In the end, it looks like it's in everyone's best interests to implement it, or of course we remain fragmented and people have to settle for Signal or WhatsApp to stay in touch with people.

@ulfi @delta Whether or how often you use a certain chat app depends on who you can talk to with it. For example, I wouldn't use WhatsApp if I didn't have a friend whose parents won't let them use anything else. And I would use Signal, DeltaChat, or Conversations/XMPP if someone I knew also used that app. (There are actually a couple people I know on Fedi I use Signal with from time to time.)

Now, assuming you and all your friends have both apps, which one you'd use then depends on how comfortable those are to use. For example, if your friends are in a group chat and group chats tend to break on one (cough cough XMPP), you'd pick the other one. If one is slow and drops messages, or is missing some important feature the other one has, such as anonymous¹ messages, chat apps, or formatting, you're going to use the other one. You're right that there is an edge towards DeltaChat on this one, though on occasion XMPP does still win (and Signal sits in the middle).

¹ XMPP MUCs have a semi-anonymous mode where the group's admin can see the members' real JIDs, but other members can't. Maybe you're a woman and you don't want men from your group chat sliding into your DMs. DeltaChat could possibly recreate this using the mailing-list pattern, but standard DeltaChat group chats can't support it.

@feld Wrapping the Rust core library and getting it to work is a battle too. IPC/FFI is not for the faint of heart, and integrating with strongly-typed languages is another story. I do understand Chatmail is more or less a standard and not a concrete implementation, though DeltaChat does offer a standard distribution.

I have a DC fork ArcaneChat alongside vanilla DeltaChat. I'll definitely take a look at that list, though. I have ideas about bridging and a standalone watch client rolling around in my head, though I'm not sure I want to be held responsible for maintaining it...

@feld That's a pretty good point. There are some okay XMPP clients, and a lot of dated and shit ones (much like IRC!), but there is only one Chatmail client -- it's like Element is for Matrix, but with no alternatives!

DeltaChat is also a lot like Element in that it is or at least feels like a fragile web-wrapper. (To be fair though, I've only tried it on Linux, where it actually is an Electron app, and Android, where it mostly just feels like a dated demo app.)

@delta You imply Chatmail is interoperable with non-Chatmail email. My understanding so far has been that Chatmail -- the newly-default mode of DeltaChat that runs on specially-configured servers -- breaks DeltaChat's core benefit of being able to communicate with anyone with an email address; this is due to Chatmail's mandatory encryption and novel key exchange protocol that isn't widely supported or used. OpenPGP and AutoCrypt do enjoy some support in niche MUAs, but most email users are on Gmail or Outlook¹ which don't support either. It may be possible to do this excruciatingly manually or with a specialized external tool (which doesn't exist), but for most people, this breaks the main reason anyone would choose DeltaChat over, say, XMPP+OMEMO.

¹ okay maybe Outlook does, if you configure it, maybe only if you're a paying enterprise user, and only OpenPGP and not AutoCrypt.

@nemobis I don't think there's any particular movement I want to see, other than away from X and Threads.

It's not busting, by the way. It's bustling.

I'm reading @cwebber's Re: Re: How decentralized is Bluesky, really?, and something she said leapt out to me here: If the only options in town are Burger King and McDonalds for food, one may have a degree of options and choice, but this really isn't satisfying to assuage my concerns, even if Taco Bell comes into town.This comparison here strikingly reflects, on the nose!, where the very real and valid concerns about Bluesky come from. ATProto in general does not fit this analogy, but the ATProto microblogging space is the exclusive domain of Bluesky. It's incredibly expensive to run, with all of the practically-centralized parts that the microblogging profile requires. Tracking replies, for example, is quite difficult to do in ATProto, and they solve this by having the Bluesky AppView (the hosted server) remember every post it comes across. That's how it knows about things like the "real" creation date of posts.

Yes, you can host your own PDS (which is the "home" for your data). You cannot run your own relay or Bluesky AppView, so to effectively microblog on ATProto you NEED Bluesky. This need not be true, but at present it is. It will take, at least, a new AppView project with a rethought architecture to create a resource-efficient alternative.

(Northwood, a new toy project of mine which is an ATProto-based forum software, is planned to approach this differently: each Northwood instance hosts some tracking metadata for each post, such as what category it's in, when it was "added" to the forum, what the last known state was, etc. It'll cache posts for a short time, to make things smoother, but it doesn't store them, and it never needs to pull the full repository.)What's missing from Mark's piece altogether is "Enable Participation". Yes, email has re-centralized. But we should be upset and alarmed that it is incredibly difficult to self-host email these days. This is a real problem. It's not unjustified in the least to be upset about it. And work to try to mitigate it is worthwhile.🎯🎯🎯

---

I'm down to the part where she started using math and I feel completely lost, but I think there's a fundamental misunderstanding of how these protocols work and are used in practice -- either mine or hers. My understanding is: for the distribution of posts on Fedi, distributing 1 post to followers on 30 different instances means that the instance has to send the post at least 30 times (or just hope that any of the instances you DO send it to, are able and willing to re-forward to the other ones). The receiving instance then has to save it to their database and distribute notifications to users. On ATProto, making 1 post means you have about 2 round-trip network requests: one from the client to the PDS, and one from a relay to the PDS. Let's pretend there are 30 Bluesky AppView instances that each of your followers are on. Each instance receives the post from whatever relay(s) they're connected to, and saves it to their database. Nothing is outgoing from the AppViews, but EVERYTHING is outgoing from the relay.

This is pretty similar to Nostr's model, and the only bit of it that I actually liked (okay the addressing thing was nice too, but ATProto's and Bluesky's approach to domain-based handles beat that out), except there is only one relay and for some reason relays are also expected to archive/copy full repositories (account data)? Although they have realized that's unsustainable and I think they've turned off their archival bits, last I've heard.

I think a lot of the problems here stem from Bluesky, not ATProto, being poorly designed. There may yet be more efficient alternative approaches -- maybe my understanding is wrong but still a better approach?

Ideas:
* Relays should mirror/fanout other relays.
* Investigate everything that requires a full copy of a repository. This should not be needed for anything, not even storage. Matrix (disclaimer: my article) and Git (MS blog) are fantastic examples of why this type of storage is a bad idea.
* AppViews need not be ready to handle every user. They should handle the posts, notifications, and followed posts of the people who actually use it -- Mastodon does this, where it stops building feeds for people who haven't logged on in a month.
* For small-world use cases, an architecture where an AppView directly crawls the repos of the follows of its users. The only thing this doesn't account for is notifications ("no missed messages"), I think...

this is giving me a headache

@cwebber i haven't finished it yet because I have a headache now and good god is it dense and long. is this how other people see my writing? no wonder nobody ever reads it. anyway.but I still do think it was one of the things that lead AP to be successful.ActivityPub is only successful because Mastodon made an incompatible profile of it to solve problems that weren't foreseen when AP was made. Nobody actually implements ActivityPub. I don't remember whether Evan or Christine said that, but one of them did, I'm sure.

To address the broader section that quote was in: I think they've failed at a few of those goals, but that's because of the Mastodon profile. I'd vote that it doesn't meet "Flexible and extensible," because extensions break compatibility, and while there's quite a lot defined in AS2, that's really all you have to work with. Or you start a brand-new type, and Mastodon doesn't understand it so for most developers, that's a non-starter. JSON-LD turned out to be a poor choice. That ended up making AP damn near impossible for anyone to implement. I tried, and I gave up. The entire C2S is really just a relic. Unless you're self-hosting, "User control of personal data" also falls completely flat: you're completely at the whims of your server administrator. (For Bluesky: they own the PDS keys by default, but you can currently take them back to move to a different PDS. This can be mitigated at sign-up but isn't for anyone except PDS self-hosters, because it's a bit complicated for the average person.) Also, "Embedded Experiences"????

It HAS achieved "Cross-Organization Ad-hoc Federation," "Feasible to self-host without relying on big players," and "Social network domain agnosticism" though. Those are pretty good, and definitely important.However, the credibility of that exit currently predicates on another organization of the same cost and complexity of Bluesky standing in if-or-when Bluesky ends up becoming unsatisfying to its users.🎯🎯🎯

NOW I've reached the end. Wow that was a doozy

@evan I wouldn't equate this with an attempted coup with the stated goal of installing an authoritarian leader despite the evidence that the claims they used to justify said coup were completely unfounded.

@jsit @evan They put at least two "soon"s in there so I assume it's not ready yet.

I wonder how they'll federate their paid profiles feature.

@evan I think I'd have to travel to see the total eclipse in person. Something I'll probably never be able to afford to do.

@evan @evanprodromou So it's like a custom like animation when that hashtag is present? Neat!

@evanprodromou @evan minor curiosity: what's the cherry blossom animation you speak of?

After seeing how the XZ maintainer's burnout and mental health decline was exploited to the potential detriment of the whole world, we're totally going to be supporting our developers more, right guys? We're totally going to fund critical OSS and pay maintainers enough to hire on other maintainers to take the burden off of them and reduce burnout, right? Right?

@evan This has got to be satire. Right?

@byjp @zatnosk @activitypubblueskybridge @fedidevs @fediversenews @snarfed@hachyderm.io If you want to block just Bridgy's Bluesky bridge, or just their (upcoming) Nostr bridge, or whatever, you can do that. If you want to block specific PDS's, I don't think there's a way to do that.

@snarfed.org@snarfed.org @snarfed @activitypubblueskybridge @fedidevs @fediversenews I'm a big fan of bridges and this is the big one I've been eagerly waiting for. I'll probably add it to my wizard soon after it's available. Once the moderation issues get sorted out, I firmly believe that in the end, this will be a net positive for both networks, since Bluesky users will be able to follow and engage with the vibrant and growing communities and services here, and we'll be able to follow and engage with shitposters from Bluesky.

The moderation issues should be sorted out promptly, and I'm a little disappointed that you're going to open it up with little consideration about mod tooling, especially considering the lists and lists of known problematic users on Bluesky, from mere crypto-shills and scammers to bigots, transphobes, racists, fascists, and genocide supporters. I don't have any way to find or use Bluesky's mod lists from here so there needs to be some other way.

Plus, I'm sure Bluesky users want a way to mass-mute and mass-block bridged users, maybe even from particular instances, especially considering our ongoing tone police and reply guy problems, which have driven numerous people from here to there. I feel like this part is imminently solvable with automatically-populated moderation list(s), though.

@bou @snarfed@liberdon.com @activitypubblueskybridge @fedidevs @fediversenews Yep.

@byjp @zatnosk @activitypubblueskybridge @fedidevs @fediversenews I think the main difference is that, like Nostr, Bluesky is just one big monolith with known problematic users (that have to be "filtered" out), so it's hard to moderate effectively. It's the same as any other large Mastodon instance, like dot Social or Gab.