Sergio
LightNews LightNews
sergio.bsky.col.social
Sergio
@sergio.bsky.col.social
270 followers 280 following 700 posts
Curious about decentralized social networks. Programmer living in Québec.Se habla español. Fuck capitalism. atp projects: https://slrpr.xyz feed generators https://atprotify.me light PDSs for everyone https://github.com/sgarciac/atproto-auth-vue-starter
slrpr.xyz
Posts Media Videos Starter Packs
Pinned
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 8d
I wrote some notes about running a PDS on cloudflare workers during my flight Toronto-Quebec : leaflet.pub/24abb069-60c... (cc @knowtheory.net @nichoth.com )
Notes on hosting an ATProto PDS on Cloudflare
leaflet.pub
1 3 19
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 2d
no, creo que no tocó. Pero tocó bregar para poder correr X windows
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 2d
El Torito CDs
1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 2d
true story: this was the first OS I installed on a PC of my own, around 1999. #rocksolid #thepowertoserve
2 1 3
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 4d
BTW, I wrote this criticism bsky.app/profile/serg... that kind of echoes your concerns, I think
sergio.bsky.col.social Sergio @sergio.bsky.col.social · Aug 9
With ActivityPub, any reasonably experienced programmer can skim a tutorial, fire up their favorite language, and, in an afternoon, code a server participating in the network, *from scratch*
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 4d
because you have to take into account that 1. the commits need to be consumed by the relay in the right order, 2. you need to be able to replay and backfill, you can’t just broadcast

I feel like this makes a stateful connection a better fit
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 4d
I don’t know the whole rationale that went behind that but I think that a model where the PDS would push updates with POSTs requests would require complex queueing and retry logic in the PDS anyway, you’ll still need a stateful persistent service.
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
Same thing for replies, and that's why in Mastodon you typically only see a subset of the replies to posts that come from other instances: because notifying every instance of new replies would be terribly costly.
1 2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
Imagine I write a post in my instance, that get pushed into 1000 other instances. Then the users of those instances start liking my post. Those instances may notify my instance, but now my instance has to also notify the other 1000 instances that saw my post that it has new likes? It does not scale.
1 2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
Think for example of "likes". In ActivityPub, federated instances will "see" different like counts for the same post. How can you keep like counters up to date for every post on every ActivityPub instance without overwhelming the network with a huge amount of messages? it is simply not possible
1 2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
I disagree. I think ActivityPub it is a fine protocol for providing some degree of interoperability between federated social networks, but you can't really build UX as compact as Twitter's without centralized indices and an efficient way to keep them up to date.
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
(no snark here, I understand your complaints)
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
I think the main reason is that it's impossible to build something that is both somewhat decentralized and provides a user experience comparable to Twitter or Instagram without moving beyond traditional web architecture.
1 2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
But I agree that ActivityPub is more hackable (as in, tinker friendly) than ATProto
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
That's more scalable than having your website pinging the N instances with subscribers to your feed, and having them keep a copy of it, every time you post something, tho.
1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 5d
Je me posais la même question... je crois que j'aurais jamais su qu'ils eteaient la...
1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
I understand that Ed Zitron is annoying, but before you criticize him, ask yourself: does an industry that has the financial backing of HUNDREDS OF BILLIONS OF DOLLARS needs your help to defend itself from a podcaster?
1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
I never thought I would witness the United States being governed by a band of online trolls.
2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
ah! Lexicon records are another thing that I find it awkward that they belong to regular PDS accounts. Regular PDS associated to an identity are not appropriate for hosting records that we'd want to be transferable, shared, etc...
1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
event PDS: PDS that exists only for the duration of an event (a conference, a live stream, whathever) where they host ephemeral posts, threads,etc. When the event ends, this "light PDS" could be discarded without affecting user identities or permanent data.
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
Bots: many automated agents don't need a full identity, just a way to publish and subscribe to records. A lightweight PDS could handle that role without the overhead of managing full account state
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
Shared feed generators: Right now, feed generators exist as records inside a particular PDS, typically owned by a single account. It feels awkward that something like a community curated feed must live under one person's namespace
1 2
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
A light PDS could be a minimal, purpose-driven node: something that can hold and serve records but doesn't need to represent a person or organization. These "light" PDS that could be ephemeral, shared, automated.

Examples:
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
I think there's room in the ecosystem for 'light' PDSs, that is, participants in the network that aren't necessarily tied to what we currently understand as a full-fledged account.
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
I’ve been thinking about how PDSs are relatively heavy artifacts in the AT Protocol ecosystem. They're typically mapped one-to-one to a user (or some anthropomorphized entity), which makes sense given the "Personal" in Personal Data Server.
1 1
sergio.bsky.col.social
Sergio @sergio.bsky.col.social · 6d
👀