Conversation

Notices

1. Embed this notice
   Nemo_bis 🌈 (nemobis@mamot.fr)'s status on Saturday, 14-Dec-2024 17:36:42 JST Nemo_bis 🌈

   in reply to

   • Blake Leonard

   @blake «"User control of personal data" also falls completely flat: you're completely at the whims of your server administrator»: unless the server administrator is accountable to you through a democratic process, which is possible and happens (most famously on social.coop).
   https://codeberg.org/fediverse/fediparty/wiki/Collectively-owned-instances

   #FediMeta

   • Embed this notice
     Blake Leonard (blake@infosec.town)'s status on Saturday, 14-Dec-2024 17:36:44 JST Blake Leonard

     in reply to

     • Christine Lemmer-Webber

     @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

   • Embed this notice
     Blake Leonard (blake@infosec.town)'s status on Saturday, 14-Dec-2024 17:36:45 JST Blake Leonard

     • Christine Lemmer-Webber

     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