So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
-
@innocentzero Relays do relatively little work, in the sense that they "just" take in records from a bunch of PDS streams on one side, and spit them out on a single stream on the other side. (Actually, they spit out multiple streams, one per client; but the basic work is the same.)
Something to be aware of is that in addition to relays, there are jetstreams; these are services that *filter* the events for you. So, if you want to run a small app, one that doesn't care about all the Bluesky posts the relay is sending you, or that only wants events for a few users, or whatever, a jetstream consumes the output of a relay, and outputs just the subset you asked for.
These services have more work to do, because they have to output a different stream for every client. They also do some things that make developers' lives easier, like convert the CBOR binary format to plain JSON, and check a bunch of the crypto for you.
At current scales? Jetstreams are still not too expensive, especially if you have few clients. If you think that the atproto network is approximately done growing, all is good. If you think it's the future of all social applications, good luck running community ones in that future.
@ricci ah thanks, I think I mixed relays with jetstreams. That makes sense.
-
@ricci ah thanks, I think I mixed relays with jetstreams. That makes sense.
@innocentzero yeah, there are a bunch of pieces to keep track of.
-
@innocentzero yeah, there are a bunch of pieces to keep track of.
@innocentzero By the way, Jetstreams were not, and still are not, officially standardized atproto objects. In fact, they don't speak atproto to their clients. They were originally a side project by one of the Bluesky team members, and have become a load-bearing side project for many of the apps that are not Bluesky.
In much the same way that some people are kind of irked at Mastodon for adopting some of its own APIs or doing other ActivityPub things in non-standard ways, jetstream is sort of a hack that solves real problems but does so off-protocol.
-
Having said that, and also disliking the fact that it came out of corpo billionaire creators of twitter, I genuinely believe there's some good stuff to pick up from that protocol.
In particular, I think the coolest part of the architecture is server-independent (more like server-migratable) identity, which is kind of amazing.
Activitypub/fediverse should adopt https://helge.codeberg.page/fep/fep/ef61/ soon, and I feel like that'd be even better than what atproto has if I understand correctly.
#activitypub #fediverse #atproto #bluesky #mastodon #federated #protocols
Nice thread. Note that it is better to refer to the official FEP location at https://fediverse.codeberg.page/fep/fep/ef61/
-
FWIW, I didn't personally find this article to be particularly snobbish or arrogant. I think it's quite well written, and while it does have a particular viewpoint and is written with a strong voice, I think it's making a good faith attempt to explain something that is a frequent point of confusion/contention when people are discussing the fediverse and atmosphere.
However, I think it uses a metaphor that's flawed enough that it's not really helping; here's my part of the thread on that:
https://bsky.app/profile/ricci.io/post/3moogiuvkjc2e
In short, article positions the data storage (PDS) as the blog in its analogy, but I think the PDS is actually more like the backend database for the blog. When people familiar with the fediverse and Web in general ask "why are there not more atproto instances" they are not asking why there are not more databases with people's raw blog posts in them, they are asking why all the blogs are served through a small number of websites.
This particular exchange, I think, helps to clearly explain the difference in how Dan and I are looking at these networks:
yes people are really asking about the "small number of websites" or "copies of the app" phrasing used in the thread.
I believe @cwebber said it before but the power lies in who runs the websites/apps and lessening the concentration of power is why we care about decentralization. the choices they make affect everyone using their services. and even if switching is possible, defaults persist for most users. and their experience changes them, and we share a society with them.
-
Nice thread. Note that it is better to refer to the official FEP location at https://fediverse.codeberg.page/fep/fep/ef61/
@smallcircles welp, thanks! Mb on that
-
@innocentzero @ricci somewhat relevant https://social.coop/@cwebber/116782178524774816
-
S silverpill@mitra.social shared this topic on
-
@angrybards @innocentzero To be perfectly honest, I think that atproto fragmenting into a one-app-per-firehose model might actually be good for it. The idea that the 'default' way to read data from the network is to read all records produced by everyone on every app on the network - well, it sounds ridiculous just saying it, doesn't it? You ain't gonna build the next Web that way, are you?
Most apps probably want to see (a) records "intended" for that app, and (b) records *about* data "intended" for that app. (think: bluesky boost of an article from a longform writing platform) (a) is straightforward with Jetstream; most apps have one or more "lexicon"s that are basically JSON schemas that they use - selecting a subset of records based on lexicon is straightforward and cheap. Right now, jetstream will let you do this, but the PDS and relays will not. I don't know of any particular reason why they couldn't however; it adds complexity, because they need to maintain different stream buffers for different clients, but I think it's doable. (b) is harder because it requires you to understand more about the records that are flying through, and, frankly, if I understand it right, the current way lexicons are used makes this quite expensive: you can reference other records by cid but that doesn't tell you what lexicon they belong to, so you have to have kept track of all of the IDs of things that you are interested in links to... basically an appview.
-
@angrybards @innocentzero Frankly, I don't know. I do know that PDSes and relays generally have rate limits built in, so I suspect that has discouraged development of any chatty apps, but again, I don't know. Large payloads in the form of images, etc. are handled via "blobs" that are just URLs to the place they are stored off-protocol. I don't know what the protocol or practical limits on records that are on-protocol are.
-
So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto
Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.
Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.
I just did a full 5 hour long stream on this blog post and more, I'm currently editing the video down for publication.
-
System moved this topic from [[category:uncategorized]] on
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login