Email or username:

Password:

Forgot your password?
Christine's posts Post Back to profile
Top-level
Christine Lemmer-Webber

@Claire @eramdam Well I mean, Bluesky's ATproto recently has made the rounds as the "more decentralized" protocol over ActivityPub, and clearly a lot of people on my Bluesky feed right now seem to think it's more decentralized, and it does have one major improvement which is that it uses content-addressed posts (I don't think the DID methods currently actually do their job though the goal is good, I can expand on that at a future time)

Which is what's leading me to look more into it, in which ways is it more decentralized in practice? Is it even particularly decentralized in practice? I'm trying to gain a technical understanding.

8 November at 16:19 | Open on octodon.social
13 comments
Clairement crevée

@cwebber @eramdam disparate repos of content-addressed objects that are truly decentralized (up to DID schemes), gathered by relays/AppViews which do not have to be centralized (but have to be huge nodes to be useful for Bluesky's purposes of a public microblogging thing)

the web DID scheme is about as decentralized as current-world ActivityPub i guess (with the nice addition of it being easier to move some details around), and the PLC one is… a very centralized placeholder?

8 November at 16:23 | Open on social.sitedethib.com
Christine Lemmer-Webber

@Claire @eramdam the DID stuff I would like to piece apart but that is a thread of its own

I was involved in early DID standardization work. I ultimately don't think this approach to DIDs solves what it thinks it's solving, but that's for later

8 November at 16:24 | Open on octodon.social
Damien

@cwebber @Claire

As a user, you could argue that ATProto is "more decentralized" because you can (not right now tho) virtually move PDSes and change names easily. But that's obviously achieved by some relative centralization.

I feel people on both sides conflate *federation* and *decentralization* (sometimes accidentally, sometimes not?) and it creates a lot of the confusion/arguments going on.

I don't know if AP or AT is more decentralized. I know Dan Abramov had a metaphor that I find a bit silly but (at least to my scrutiny) holds up:
- AP/federation is having to choose where (neighborhood/country/what-have-you) you build your house
- AT is like having to choose an internet provider. (source: bsky.app/profile/danabra.mov/p)

The latter is sold as a positive, but that obviously means you're dependent on like... everyone else above "you" not being shady :P

@cwebber @Claire

As a user, you could argue that ATProto is "more decentralized" because you can (not right now tho) virtually move PDSes and change names easily. But that's obviously achieved by some relative centralization.

I feel people on both sides conflate *federation* and *decentralization* (sometimes accidentally, sometimes not?) and it creates a lot of the confusion/arguments going on.

8 November at 16:29 | Open on social.erambert.me
bryan newbold

@cwebber @Claire @eramdam don't think the goal w/ atproto is to be "more decentralized" in the abstract. we (team) had worked on SSB and dat, which were radically decentralized/p2p but hard to work with and grow. would not supplant "the platforms".

atproto came out of identifying the *minimum* necessary decentralization properties, and ensuring those are strongly locked in. we basically settled on:

8 November at 19:00 | Open on social.coop
bryan newbold

@cwebber @Claire @eramdam
unbundling and composition: ability to swap components w/o swapping full stack.

credible exit: ability for new interoperable providers to enter network. public data must be accessible w/o permission, and schemas/APIs declared

control identity: whole network/proto doesn't need to be individualist, but identity is personal

easy to build new apps: don't build for the old modalities, enable new modalities. accomodate opinionated devs.

@cwebber @Claire @eramdam
unbundling and composition: ability to swap components w/o swapping full stack.

credible exit: ability for new interoperable providers to enter network. public data must be accessible w/o permission, and schemas/APIs declared

control identity: whole network/proto doesn't need to be individualist, but identity is personal

8 November at 19:04 | Open on social.coop
bryan newbold

@cwebber @Claire @eramdam I have a longer post on this, and our progress, on my personal blog:
bnewbold.net/2024/atproto_prog

8 November at 19:04 | Open on social.coop
bryan newbold

@cwebber @Claire @eramdam
I think a bunch about this post about the history of mp3 piracy and "minimum viable decentralization":
web.archive.org/web/2018072520

(though it wasn't directly influential on atproto design, and Backus has since pulled the post)

8 November at 19:16 | Open on social.coop
Risotto replied to bryan

@bnewbold @cwebber @Claire @eramdam

don't expect a tracker company that plans to make money on the big data of tracking torrents to fully embrace the magnet file specification or the DHT in favor of their cure.

e.g., the "VPNs cure everything" of social media

you can't make someone learn that which their job depends on them not getting.

8 November at 19:18 | Open on tech.lgbt
bryan newbold replied to Risotto

@risottobias @cwebber @Claire @eramdam the value of data-for-sale is usually proportional to how exclusive access to it is. if data is public, it is commodity and "worth" a whole lot less.

IMHO client apps are way under-appreciated in this regard: they can track attention/behavior way better than API servers can.

8 November at 19:30 | Open on social.coop
Nemo_bis 🌈 replied to bryan

@bnewbold Thank you Bryan, this is extremely helpful!

I hope to see multiple #BlueSky relays soon (incentives unclear: neuromatch.social/@jonny/11336). I worry about the climate costs of many full copies.

One accidental design feature in #Mastodon is how an instance serves as "relay" with a cache of posts and media caused haphazardly by whatever happens to federate. This is messy but flexible. masto.host/re-mastodon-media-s Instances can share deduplicated object storage. jortage.com/

#FediMeta

@bnewbold Thank you Bryan, this is extremely helpful!

I hope to see multiple #BlueSky relays soon (incentives unclear: neuromatch.social/@jonny/11336). I worry about the climate costs of many full copies.

One accidental design feature in #Mastodon is how an instance serves as "relay" with a cache of posts and media caused haphazardly by whatever happens to federate. This is messy but flexible. masto.host/re-mastodon-media-s Instances can share deduplicated object storage.

Jortage storage service for Mastodon instances: « The Storage Pool project is currently storing 41.80TiB across 122.93 million objects for all our members. Without deduplication, it would be storing 93.52TiB across 290.83 million objects.» «Let's talk about a simplified real-world example. Someone with 1,000 followers, across 100 instances, makes a post with 4 media attachments, 2MB each. Those 100 instances are pushed the status by the original instance, and they all immediately download it from the original instance. This causes a surge of traffic, totalling 800MB. All these instances then upload this media to their storage provider, and if multiple of those instances are using Backblaze, then Backblaze themselves performs deduplication, but doesn't share the benefit. The fediverse has just grown by 804MB, and any Wasabi-using instances have to pay for that for at least 90 days, even if they delete it. Let's say 10 of those instances use the Jortage Storage Pool, and so does the originating instance. The standard case has the same surge in traffic, but instead of 80MB being stored for those 10 instances, 0MB is stored, because Jortage already has the files. Additionally, the traffic surge is absorbed by our CDN, being designed for precisely this kind of issue. If the original instance doesn't use Jortage, then only 8MB is stored. The traffic surge is difficult to prevent due to how Mastodon's media upload system works, and the facts of how S3 works.»
9 November at 8:20 | Open on mamot.fr
Luca Sironi replied to Nemo_bis
@nemobis @bnewbold

very interesting, but if we bring decentralization to the extreme of almost personal server, up to say 100 users, which is a thing activitypub allow to do with bare minimum hw/network...

there is no need to have a remote storage for caching media.

A server with reasonably few users, download just a fraction of media from the fediverse, and don't have to keep them forever.

We are chatting, not mirroring the whole internet.
If you see something on internet, a beautiful picture, a long article, and you like it, you save it, you don't expect it to find it online next year
@nemobis @bnewbold

very interesting, but if we bring decentralization to the extreme of almost personal server, up to say 100 users, which is a thing activitypub allow to do with bare minimum hw/network...
9 November at 9:33 | Open on sironi.tk
Risotto

@bnewbold @cwebber @Claire @eramdam

my counterpoint to that is, like trying to run your own version of the architecture for e.g. 11ty, it locks things into a scale and architecture that requires full time devs.

what people need for "'credible exit" is a dead simple system.

something that a small, non-venture-capital, organization can reasonably host. think cohost's budget.

going for "you of course need 8 full time engineers" level complicated isn't decentralized.

needing a full time rails sysadmin isn't great in mastodon's favor, but it's getting better.

this is similar to saying "static site generators and hosting are viable alternatives to WP" when wordpress is easy enough for people to spin up and use, and there's a viable ecosystem for it, for newbs to run.

WP has a lot of inefficient resources when all they need is a static CMS, but it got the deployment story right.

@bnewbold @cwebber @Claire @eramdam

my counterpoint to that is, like trying to run your own version of the architecture for e.g. 11ty, it locks things into a scale and architecture that requires full time devs.

what people need for "'credible exit" is a dead simple system.

something that a small, non-venture-capital, organization can reasonably host. think cohost's budget.

8 November at 19:15 | Open on tech.lgbt
bryan newbold

@risottobias @cwebber @Claire @eramdam
I'm not sure I understand 11ty; is that 11ty.dev/?

for me credible exit means being able to replace the largest operator, who is indexing the full network. if the network is large, such an index is going to be large! spinning up a cozy/indie/small network is good, and important, but the full-network thing is also important in society.

8 November at 19:23 | Open on social.coop
Go Up