Wow, I always imagined Activitypub to be the better protocol and AT a cheap knock-off, but reading this article made me realize at is, actually, way better - primarily because multiple programs can access the same identity. This is really a great feature to have! This article was a real mind-opener for me.
Every one of these "How AT proto works" explainers focuses on data ownership—which is where ATProto shines—and glosses over data processing, where ATProto is decidedly weaker than ActivityPub.
ATProto is built on a global, public view of the world, where all events are visible to a trusted global "AppServer" that can make all of the decisions for you—how to create your feed, who can see who's posts, etc—all of those decisions have to be made by a trusted intermediary. ActivityPub is more like RSS or email—your local server only has to manage the feeds you subscribe to, and your inbox is directly built from all of the posts you have access to. People you subscribe to send you your posts, and you don't have to process them at all.
This is why Bluesky could never have "private likes" in the same way Twitter or ActivityPub does—every AppView needs to track the like counts of every post in the network manually. It's a huge hassle! I just don't see this architecture winning out in the long term, when compared to the AP feed-subscription architecture.
primarily because multiple programs can access the same identity
Actually, this was how AP was originally designed as well—it was just that the most popular early implementations took shortcuts to remove that functionality to fit them into their existing architecture. This is a direct consequence of the fact that the biggest AP implementations when it was initially adopted were descendants of older OStatus social networks, and not built to be "ActivityPub-native" from the ground up.
> This is why Bluesky could never have "private likes" in the same way Twitter or ActivityPub does
I didn't know "private likes" even existed, but if atproto includes public key encryption, I could publish a record containing a "like" that I have encrypted with the "liked" user's public key. Only that user would know what the record contained. Though, the fact that the encrypted message exists and had a cleartext "@name" is itself informative to adversaries. Concealing that level of info would require other measures.
Correct. All information in the system is part of a public, append-only ledger. That's the thing I'm pointing out is a fundamental weakness of the system.
I think the lack of owner's custody of the private key in bluesky is more the result of a convenience design than of a technical limitation. If the user is expected to manage the private key, you might end up with something similar in complexity to Nostr. But it might still be possible if you're running your own PDS.
I haven't worked with Fedify before, but what I'm talking about is the difference between a service that has a "translation layer" between their own internal data model and ActivityPub, and a server that actually stores full ActivityPub object's in the user's inbox and outbox, and displays them unchanged to clients. 90% of deployed ActivityPub applications—like yours!—are the former, not the latter.
A true "ActivityPub server" is almost as simple as a Bluesky PDS—all it's responsible for is 1) storing blobs of data, 2) fanning out subscriptions and 3) collecting incoming data for you to view. In the original way ActivityPub was designed, all of the actual data presentation layers—Mastodon, PeerTube, Pixelfed—were designed to be specialized clients that could communicate with the user's generic server. However, the first popular implementations cut out the client-to-server part of the protocol, so now we're stuck in a place where everyone thinks ActivityPub means you need a separate identity for every client application.
So, what I would recommend for your own username/password site is implementing an ActivityPub client, and recommending that users use it to connect to a third-party ActivityPub server. That way, the user owns the data, and they simply use your service to get access to (filtered version of) it.
Unfortunately, since this is a less implemented part of the protocol, the client APIs necessary to make this a reality haven't seen much development. And you're facing an uphill battle for user adoption. In practice, users don't seem to mind having separate accounts and identities for different clients. It reminds me a bit of the "key management problem" in e2e cryptography. Having a stable cryptographic identity is doable if you're technically minded, but most people just muddle along and don't really care about it that much—they create new keys every time they get a new laptop instead of trying to figure out cross-signing, and everything works itself out more or less fine.
I mess around with fedify a lot, it's great. It's fun to integrate with existing websites.
I've thought a lot about ATProto and integrating it in similar ways. I'd love to have a look at what you're doing and how. The struggle I have is that I think the ATProto repos have a fairly strong cryptographic structure compared to AP
If someone requests an object over AP, that object contents can come from anywhere easily, and can be signed easy. So for me, when someone requests an activitypub object of one of my notes via fedify, it just reads the truth from my markdown note files and returns it. If I edit my markdown files, it's no real issue, the next request gets the latest version of that markdown (there's some signing nuances in places, but it's generally straightforward)
With ATProto PDS and repositories use things like Merkle Search Trees and other things which I assume means the backend data needs to be a lot more... consistent. Like the data has to live in the PDS, and that has to become the source of truth to maintain the merkle structures, including updates.
But with AP via fedify, it feels super easy and nice for my source of truth to be whatever backend store I like (markdown notes).
I've done enough with crypto to see the benefits provided by the transparent verifiable history of merkle like structures, but honestly, this is social media not cash: I don't care if someone wants to subtly change something to manage how they come across with their own social media. In that respect, I feel the ATProto repositories overcomplicate things a bit.
> We should pick a platform that is federated, where you have ownership and autonomy over your identity and your audience. Social media should not be own-able by a single group or person. Social media is serious business. It ties directly to human rights and business outcomes. It shouldn't be in anyone else's control but yours.
I agree, but why not also apply the same logic to the other two communication platforms you are using (Discord and GitHub)?
Interesting discussion, and good points highlighted about Bluesky's did model that means you essentially don't own your identity either (in typical scenarios and when it will likely matter most). That takes a big chunk out of the "host your own data" narrative.
One point I disagree on that's also mentioned in the replies: I don't think a global state should be seen as necessary or even desirable. Sure, it helps people who optimize for clicks/likes/attention as a business model But that shouldn't be the only concern. Having some degree of uncertainty around the global state can help reinforce a healthy skepticism towards what you're seeing in general. The 'correct' global number of upvotes on a post, or the majority of what has been said about a subject might still be manipulated to the point of being essentially fake. Optimizing for virality is not desirable if you think of the platform as a public good. Think about what it has done for the centralized platforms, and the consequences it's had in the real world.
This is not meant as a criticism at all, I like Bevy. Are you familiar with the Mr. Beast PowerPoint that said:
> Your goal here is to make the best YOUTUBE videos possible. That’s the number one goal of this production company. It’s not to make the best produced videos. Not to make the funniest videos. Not to make the best looking videos. Not the highest quality videos.. It’s to make the best YOUTUBE videos possible.
When I glance at the Bevy discussion link you shared, my reaction is:
> Your goal here is to make the best GITHUB OPEN SOURCE game engine possible. It's not to make the most performant game engine. Not to make the game engine that powers the best games. Not to make the best looking graphics in a game engine. Not the highest quality game engine or game editing experience. It's to make the best GITHUB OPEN SOURCE game engine.
> Your goal here is to make the best GITHUB OPEN SOURCE game engine possible.
That sounds awful if applied to Bevy, and seems you misunderstand what "Mr. Beast" is trying to say.
They're not saying make the best game engine, but make the game engine that would do best by GitHub-popular metrics, which is absolutely the wrong way to go.
I hope they continue to simply make the best game engine available, as before, and ignore useful metrics or focusing on where it's hosted.
They didn't misunderstand, they're calling out Bevy's priorities.
Bevy is still incomplete as an engine. AFAIK there's only one commercially successful game made with it, Tiny Glade, and it doesn't even use Bevy's renderer but a custom one.
Yet the Bevy developers distract the project with essays and debates about the politics of their federated social media presence. You don't need that to build a game engine, but you do to build a "GITHUB OPEN SOURCE" game engine. I don't think there's anything inherently wrong with it, but that's clearly the focus here.
> They didn't misunderstand, they're calling out Bevy's priorities.
Yes, but the misunderstanding I'm trying to point out is that Mr Beast is not trying to create something of value, they're trying to create something that works well on a specific platform.
In the Bevy analogy, that would be creating a GitHub project that gets the most stars, regardless of how useful or well the engine itself is working.
I'm instead saying the same thing as you, they should continue focusing on building the greatest engine, regardless of the platform for hosting the project.
If Bevy were to follow Mr Beasts advice, they'd focus on flashy demos, engaging READMEs and so on, to increase the success on the platform itself, instead of focusing on the engine itself, which from following their direction almost since inception, they're doing a pretty good job with already.
If your goal is to be viral and not care about the quality, then maybe following Mr. Beast's advice might make sense. If you'd rather risk popularity by trying to what you think will actually be better without knowing whether it will end up being viral, it makes sense probably to take anything he says with a grain of salt.
I guess my point is, writing 3,000 words on social media choices isn't going to make the game engine any better. But I can see how it is really important to the community and developers, which is to say, it's really important if the product is not a game engine but An Open Source (Esoteric) Game Engine Hosted On GitHub. Do you see what I am saying? That is the difference between making the best videos and making the best YOUTUBE videos. Mr. Beast isn't confusing, he's capitalizing the important part of what he is trying to say!
I fully understand what you're saying; I just don't agree with it. For starters, people can be complex and have more than one goal. The effect of making an open source project isn't necessarily just the utility of the project itself, and if some of those other potential effects are desired, the best way to do things won't necessarily be the same as if there's only one output that someone cares about.
For another thing, even if there aren't any other specific effects that are desired, there still might be some that are specifically not wanted, and avoiding those might be important. Mr. Beast is a exactly the type of example that demonstrates this point; by focusing on making the "best" YouTube content as measured purely by popularity, he's done all sort of things that someone might very understandably want to avoid. I agree that he's not confusing, but that's not the issue with him. He's extremely transparent in how little he cares about whether what he does actually helps anyone other than himself (or if he hurts other people in the process of helping himself). I suspect this is quite different from the mentality of most open source developers, who are putting in personal time and effort towards contributing to something that realistically has little likelihood of direct personal benefits for those involved. What you're perceiving as a lack of focus comes across to me as having the humility and thoughtfulness to try to look at the big picture and understand one's actions in the context of a larger environment that isn't improved in the long term by pursuing a single narrow goal to the exclusion of literally everything else.
Okay… Unity and Unreal have a lot less focus than Bevy, but are much better game engines. They will be shipping more great games every day than Bevy will in the next year, including beloved meaningful ones, like Silksong and Indiecute and Cuddlygame or whatever. And hardly anyone there, like most big corpo employees, is directly benefitted from the better games, they get paid the same amount of money, but the rub is also, everyone I know working at Unity and Epic is really sincere and loves games.
Of course I understand these are different things. Bevy is not at all competing with Unity.
Because Bevy is trying to be best GITHUB OPEN SOURCE game engine. I’m just trying to be a little jocular about how… you know, I didn’t say unfocused, but surely it seems a little silly to write 3000 words in response to a community worried about which open source social media federation protocols to adopt. That giant thread IS the product, it makes perfect sense from the POV that Bevy is trying to be the best OPEN SOURCE GITHUB GAME ENGINE, in the same way that Mr Beast is making the best YOUTUBE videos or Egyptology professors are making the best EGYPTOLOGY writing or painters are making the best PERSONALLY MEANINGFUL FINE ART or whatever. I like Bevy!
> Bevy is trying to be best GITHUB OPEN SOURCE game engine
You're the only one saying this. No one else, including the person working on the project that you originally responded to, have claimed this is their sole goal to the inclusion of everything else. It's hard to tell if you think they literally don't care about anything else but are choosing their actions poorly, or if you think that they have the wrong priorities and should change them, or if you just didn't really stop to consider that maybe your assumption about what you're saying they're trying to do is incorrect and haven't read what I'm saying closely enough to understand that no number of examples of other things that happen to fit what you're saying is relevant if you aren't able to establish why anyone else should agree that it applies here in the first place.
One could argue the opposite, let's take bevy as an example:
more popularity could bring in more contributors or more funding which would hopefully result in making a better engine.
The same could apply to Mr. Beast videos (more views translate to more money which translate to better production and staff which translate to more or better videos) but the goals are inherently different (maximizing profit which rewards quantity over quality)
Community drama has always been the achilles heel of large, open-source projects which are volunteer driven. Focus on community is critical to delivering this, especially when your product relies on mind share.
Yea maybe! I think at:// is an even stronger brand in a sense though. Actually makes sense as something browsers may support one day, “at://alice.com” makes sense at “stuff at alice dot com”, “authenticated transfer” is a decent acronym, “atmosphere” for the ecosystem is just great (and wasn’t even coined by the team).
It’s worth noting that PLC can’t fake your data because each edit is recursively signed. So you can verify a chain of updates. However, PLC can in theory deny you service or ignore your updates.
Yeah, there are tens of thousands of records referencing a PDS with a certain… controversial president's name in the hostname, which doesn't actually exist at all.
Also someone from Nostr made a tool that let you upload image files and encode them (split into parts) into plc directory records…
> primarily because multiple programs can access the same identity
Why do you think that's different in ActivityPub? As far as I know there's nothing preventing (for example) Mastodon and Pixelfed using the same identity.
Responding to the proposal (which is unjustly flagged to death, even if I agree that it isn’t a good idea):
> I came up with a solution that eliminates centralized control, trolls, advertising, and really all forms of harassment, and it doesn't even require a special server.
If it behaved as you describe (only followers see top-level updates and only followers of every person i the chain see replies; which I don’t think the concrete features you describe actually support, but I’ll get to that next), then it also eliminates the thing that makes social media work for both audiences and the people looking for audiences—there is zero discoverability, you can’t even encounter people through conversations.
Of course, with public outgoing feeds where visibility limits are a decision of the viewer’s client (to which all the visibility-deciding work of a server is outsourced, to avoid having a dedicated social server and just rely on regular web pages), it can’t be guaranteed to work that way. It can work that way for a viewer who wants to see that restrictive of a view, but that doesn’t prevent other people from having a more expansive view.
You can choose what you see, but not who can see your stuff or who can engage with it (if you have a client that behaves in the described restrictive manner, you won’t see engagement from people you don’t follow, but they can engage and others with a permissive client can see that engagement.)
> there is zero discoverability, you can’t even encounter people through conversations.
based on the spam and harassment on most social sites, I'd call this a feature.
If you read something interesting you can email the person with your thoughts , and if they find it interesting they'll follow you. If you are a troll, they'll delete your message and they don't need to use their platform to support your comments. If everyone used this system, trolls wouldn't have a platform anymore.
Herman from bear blog posted about a topic, a bunch of people emailed him their thoughts, and he created a follow up post with the best of those thoughts listed out.
This system definitely won't work for people that have FOMO, or need validation through votes on their comments.
> How do you facilitate discovery? IE, what if I want to know about replies people have made without subscribing to their /social page?
That's what makes this system so great, you don't see what other people you don't even know say, and you should be ok with that. Don't look for validation from the trolls on the internet. Reading what random people you don't know say is how you get spam and harassment.
> How can I add this to my website?
currently this is a thought experiment, but if anyone wants to work on it, let me know, my contact info is on the post.
Also, this wasn't meant as "the solution" to the problem, more just maybe we should be looking for small solutions that don't require a huge amount of infrastructure to run.
> That's what makes this system so great, you don't see what other people you don't even know say
But how do you get started? Are you saying you only look at blogs of people who you've met in real life and who told you their blog URL? Even that is unrealistic because lots of blogs link to other blogs. Why should I be okay with following a link from one blog post to another blog post but not okay with seeing a comment on a blog post?
