Email or username:

Password:

Forgot your password?
Christine's posts Post Back to profile
Top-level
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.

8 November at 19:04 | Wall-to-wall | Open on social.coop
6 comments
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
Go Up