#AskFedi: are there any recent, smart articles about #ATProto and its half-baked decentralization (so far)?

Michael Foster

Here’s my non-technical take! If you come at this from a server/PDS based approach then it’s easy to argue Bluesky hasn’t yet decentralised much. But if you look at the Atmosphere as a whole there are many components, in particular Custom Feeds (and less successfully composable moderation) where Bluesky is heavily decentralised. Blacksky is amazing for example, as is the Science Feed. Or Quiet Posters. All these feeds are run by volunteers from the community

Michael Foster

@_elena also here’s a link to a thread from one of the team which is an interesting description of how some of it works

https://fed.brid.gy/r/https://bsky.app/profile/did:plc:ragtjsm2j2vknwkz3zp4oxrd/post/3l6xwi52zti2y

Kristian

@thisismissem Thanks, interesting read. Actually, despite the still disputable take on decentralisation, I still consider ATProto/Bluesky to be ahead of ActivityPub when it comes to data portability (as in "not losing all your posts and comments if you have to move to a different instance"), and I'm way less applauding Bluesky for that than rather seriously wondering why ActivityPub specs have missed out on something as crucial ad that.

@rysiek @_elena

Emelia 👸🏻

@z428 @rysiek @_elena to be honest, there's a lot of things the AP specs either didn't define or poorly defined. E.g., there's no real description of how the Block activity should work in a ssrver to server context.

Kristian

@thisismissem Yes, I know. Data portability seems just the most striking and confusing example to me, also because solutions for that have been around and predate the AP spec and Mastodon, looking in example at Hubzilla. The Bluesky approach, too, of comparing "your personal data" to something like a git repository which "of course" is not tied to a hosting service like github or gitlab seems painfully obvious.

@rysiek @_elena

jonny (good kind)

@thisismissem
@_elena
There's definitely a cultural difference at play where they say this like its a bad thing:

You will have to make sure nobody stores things against your rules, nobody shares it, none of it comes in and none of it goes out.
It also means you communicate directly with other people participating in the network, and store incoming data from them, but you already know that.

To me, as much as I think it would be great to have less monolithic instances, arriving at shared social norms, having responsibility for each other in the commons, and communicating with each other about what we want things to be like strike at the core of what makes left-libertarianism/anarchism different than right-libertarianism anarcho-capitalism.

Is freedom the right to be rid of each other? Or to take on the radical responsibility for each other?

Elena Rossini ⁂

@z428 thank you. could you please tell me more about Hubzilla and its data portability?

(I tried and loved Friendica and I'd been meaning to try Hubzilla too)

Elena Rossini ⁂

@michael Yes! I've been on Bluesky (albeit mostly lurking) since April 2023 (I'm the 1%) and I really admire their custom feeds.

Fun fact: Friendica also has some custom feeds (including "quiet sharers")

Michael Foster

@_elena Will check that out!

Kristian

@_elena Very brief summary on that: In Hubzilla, you have your posts and communication living in a channel that can have multiple clones on different instances. So in case you lose access to your main instance (because it goes down or is discontinued or the admin decides to block you), you still have access to your history in there. In Mastodon or even Friendica, such a scenario would completely strip you of all your previous data as even though you can export your full history manually, you can't re-import this anywhere except for the contacts. In some systems like pixelfed, not even a full data export is possible. Not sure whether this is an individual requirement of mine but it feels very difficult from an "own your data" perspective. On Mastodon, there's a change request - github.com/mastodon/mastodon/i… - for that which hasn't been implemented yet.

cc @chris and @jupiter_rowland who know the Hubzilla details much better than I do. (Mostly Friendica/micro.blog user here.)

morph ⌂

@Kristian @Elena Rossini ⁂
The Forte project's goal is to put nomadic identity on top of ActivityPub.

Kristian

@morph Yeah, there's an FEP - socialhub.activitypub.rocks/t/… - for that but whether or how this is going to be implemented by a reasonable amount of platforms remains to be seen. Having this at the core of the standard would probably have been a better option. But maybe I'm just too pessimistic here.

@_elena

Debbie Goldsmith 🏳️‍⚧️🏳️‍🌈

@thisismissem @_elena @rysiek I might be getting something wrong, but doesn’t the model for relays strongly incentivize them to be large and centralized?

Emelia 👸🏻

@dgoldsmith @_elena @rysiek pretty much, yes, due to operational costs: you've basically gotta process absolutely everything ever posted from what I can tell.

Sure, extremely large mastodon servers *can* be expensive to run, but there's also a lot of servers that are incredibly overprovisioned and have loads of excess space.

Erin 💽✨

@thisismissem @dgoldsmith @_elena @rysiek I don't think the costs of relays are *too* bad. How you bootstrap a new one is an interesting question however

AppViews are the true centralised headache though; you can build one, but it's going to be *big* or you're going to be working against the protocol

Erin 💽✨

@thisismissem @_elena @dgoldsmith @rysiek in some ways the Mastodon FASP proposals replicate aspects of the complexity of an AppView, but they do differ in that they're fundamentally complementary to the federation protocol itself

Emelia 👸🏻

@erincandescent @_elena @dgoldsmith @rysiek I am also hoping that for FASPs we reuse the ActivityPub representations of objects/activities as much as possible.

We've already shifted from OAuth 2 for both Server and FASP to HTTP Message Signatures using public/private key pairs where the public key is exchanged at registration

Erin 💽✨

@thisismissem @_elena @dgoldsmith @rysiek yeah the way I see it is that instance-to-fasp (indexing) should basically behave like an outbound only relay; fasp-to-fasp could even just straight up behave like a relay

Emelia 👸🏻

@erincandescent @_elena @dgoldsmith @rysiek I'm not sure how FASP to instance should happen exactly, but I'm thinking AS2 representation probably makes a lot of sense here too.

Renaud Chaput

@erincandescent @thisismissem @_elena @dgoldsmith @rysiek the current plan is for the instance to (batch) notify the FASPs with object identifiers, then the provider can fetch them (if they want: depending on freshness, deduplication blocklists…) and ferch them from the original inbox, from their own actor