A rant about social protocols Introduction
Recently, I read an article that talked about that someone, tried to do a new platform called “Content Nation”. This is a German platform that allows people to write content (to be honest, I don’t really know what it does.) and publish it. And recently, the creators tried to implement the ActivityPub protocol. They did so by using the official documentation provided by @w3c.
The problem was that the last time the official documentation was updated, was in 23 January 2018. So, this means that a lot of new standards that other platforms like Mastodon, Misskey, etc... use are not written in there. But this isn’t the fault of the service developers, this is the fault of the W3C that hasn’t been an update to the protocol officially to support the new standards in the industry such as Webfinger, SharedInbox, Privacy Scopes, and Opt-Out for Search…
The thing, is that this led to a lot of people thinking that this site was some kind of scraper and started making the crawler crash or, even worse, someone tried to load CP inside the platform. BlueSky
Recently, BlueSky opened its AT protocol for everyone to use and federate, due to this, there has been a bit of a discussion inside these platforms. This made me think, why did BlueSky feel the necessity to make another protocol? If there is one already, why do we need another one that competes, wasn’t the objective of protocols to allow interoperability?
So, I did a bit of digging and I found two things. The first one is that they wanted so solve a few things that AP does not support officially (here are the main points, not all of them):
Account portability. A person’s online identity should not be owned by corporations with no accountability to their users. With the AT Protocol, you can move your account from one provider to another without losing any of your data or social graph.
Algorithmic choice. Algorithms dictate what we see and who we can reach. We must have control over our algorithms if we're going to trust in our online spaces. The AT Protocol includes an open algorithms mode so users have more control over their experience.
A lot of these problems are already present on ActivityPub for a long time. The account portability of ActivityPub let’s say it’s not intuitive. You have to do a lot of things and even then, there are some things like the posts that you make or the favourites that don’t transfer (in the case of favourites you need to transfer them manually, the same for blocks and mutes).
Also, right now 99% if not all software that uses ActivityPub, does not have an algorithm that orders content for you to see, but shows you everything in chronological order (I don’t know if its intentional or if it’s a limit of AP) and the only thing you have to discover topics is trough hashtags that maybe someone forgot to tag.
Furthermore, not to mention that on ActivityPub, you are at the mercy of the server moderators, so this means that if you know someone that is on an instance that is blocked by yours, you won’t be able to talk to them unless you change the instance, which in a way it’s not very decentralized. The other protocols
By doing research, I realized that there are a lot of other protocols (for example Nostr) that have its own implementation of things maybe there are some that are bridged and other not.
Such protocols have different features, for example Nostr allows you to suggest content edit to other people’s posts, move your content easily, etc. How can we solve this?
First, we have to know why all these other companies make their own. I must say, that most of them probably do because AP does not allow customization of posts or the adding of new features for everyone and the fact that it’s not been updated for 6 whole years makes matters worse.
What the developers want, is a protocol that lets them create wherever they want and add everything the want, for example the edit thing that I said the Nostr supports, the only way to add it to AP, would be or only on your software or find another software that is willing to implement that feature, the rest of the market is left behind as well as the users that depending on what it is, they don’t understand.
My solution to this problem would be to add some kind of per user plugin system directly to the AP that allows for devs to implement add-ons that do with the JSON strings that add buttons or scripts at least to send and receive data. As well as to add some kind of CSS support for the posts and profiles. Of course, the point of these is that if you make a platform, and you are the only one using these characteristics, well… but in case that everybody wants to use it and everybody makes their own plugins it would be chaos.
For this, the solution I proposed would be like something you add while the W3C updates the protocol to support a very popular feature. #socialprotocols#nostr#activitypub#W3C#ATprotocol#rant#blogpost#ContentNation
@mmasnick this is super helpful. But one question I still can't quite grasp.
In the #ATprotocol server space, do the server admins themselves have the ability to ban users or remove content regardless of and prior to the users choosing their own moderation filters?
I also can't tell if the BlueSky/ATprotocol space allows for admins also have something analogous to #Fediblocking users and content from other ATprotocol servers.
The sandbox environment has now been launched, which means you can set up your own AT protocol-enabled server.
It's possible that Bluesky will finally start federating by the end of summer. However, knowing how most dev teams work, this launch is not a certainty. It always takes time to iron out bugs.
How successful do you think Bluesky's federation will be? And how will it impact the current userbase using Bluesky?
#Bluesky 's latest blogpost [1] reveals that the #ATProtocol is a classic bait and switch game, facilitated by the small-world/big-world distinction. [2]
The bait is telling creators that their content is safe (from petty moderators/server shutdown) and that they are not locked into a platform because the AT protocol is federated, so they can self host with a handle under their control. The switch is that the (federated aspect of the) AT Protocol is irrelevant in the big-world.
From a preliminary ~12h sample of #bluesky / #atprotocol , a small number of accounts receive most interactions. This is an obvious byproduct of the way the default algorithmic feed prioritizes posts.
5% of accounts received 72% of likes, 1% of accounts received 41%
The top 5% of accounts make 48% of posts
37% of accounts receive no interaction
The median account received 1 like.
Just a quick, incomplete look, but ya looks like an engagement farm
I was very impressed with how easy #BlueSky makes it to claim a domain name handle.
I uploaded a small text file to .well-known and my account is now "@edent.tel"
I'm not convinced that #ATprotocol is brilliant - but Mastodon server providers could learn from the simplicity of getting a personalised domain up and running.
A major difference between the #ActivityPub federation and the #BlueSky#Atproto (#Atprotocol) federation is that under AcitivityPub, used by Mastodon, all servers that need to send or receive data from other servers need to make direct connections to each other. This means many queued jobs and many connections, maybe thousands. This leads to the classic sidekiq queue problems when Mastodon instances have numerous users with numerous follows, and relays.
In contrast, in atproto, the user's PDS, Personal Data Server, doing equivalent work of a Mastodon server, for example, only makes a few connections to the relay server's fire hose to deliver and pick up messages. It never connects to any other PDS directly. Theoretically, a tiny #PDS on atproto can handle a considerable number of users. This seems to be an advantage.
Mastodon admins spend a lot of time and money fighting performance issues, database connection counts, and sidekiq queues because the server has to talk directly to other servers. But the PDS only needs to talk to maybe one, or possibly a few relays to get and send messages.
Here's a diagram of the atproto architecture. It appears quite a simple architecture.
He wrote a great article back in January entitled “Moderate people, not code” that is good background
> “Whether ActivityPub or ATProto or webmention, the underlying technical protocol a community uses to interact online is a poor way to judge who they are and whether you might like them.”
OK even funnier than #bluesky / #ATProtocol 's plc DID method relying on a single domain is that the hardcoded DID for bsky.app isn't registered, they don't even use it for the default algorithms and just hardcode a workaround.
WHICH MEANS that whoever finds a (truncated) hash collision for the bsky.app DID will cause an absolute fucking mess hahhahaahhaah
alright I'm going to boot up one of these #atprotocol graph indexers and start sampling the firehose. even doing that feels like an invasion of privacy but I gotta know what ya can do with that
I'm studying the docs, and I have a question for those who might know better:
The big thing AT is promising is better portability across instances (when such instances appear). My understanding of the docs (https://atproto.com/guides/overview#account-portability) is that this is made possible, in part, by having a copy of my data on my client.
So, I do have a bsky.app account. Where is my local data? I don't see any anywhere. Is that not implemented yet?
The only thing I love about Bluesky / AT Protocol is the use of subdomains for user names.
The double-@ is confusing as heck to people, but a link that also works as a mention name is obvious / intuitable (eg "Find me at jeremiahlee.bsky.social which makes me mentionable @jeremiahlee.bsky.social").
Rather than starting a #Mastodon vs. #BlueSky war, is there any way to build a bridge between #ActivityPub and #ATProtocol? If both are open standards with roughly comparable functionality, I wouldn’t have thought this should be too difficult, with some limitations. Thoughts? #noxp
The whole idea of BlueSky supporting nomadic identities but the rest of the ActivityPub (plus other stuff) Fediverse being unable to do so is such an oversold idea.
A new service using ActivityPub behind the scenes (and not the AT Protocol) can absolutely support nomadic identities, even if the service doesn't treat a whole website as the actor.
It will still use did:plc, same as AT Protocol (BlueSky), but once done so, an application that understands how to work with did:plc can dereference an actor based on the DID.
That said, an existing service will simply not be compatible with this idea, without changing how it operates.
Question about webfinger: if I give it an actor @foo, it's going to query directly to bar.social, right? There's no way to somehow, register a proxy for something? I guess that would be a security risk, no?
My goal is to try to figure out whether I can make some kind of bridge for ActivityPub and ATProto, without touching either codepase directly, since making either one be able to talk to the other is a political issue right now. While code-wise I think it's possible to translate between them, at least with follows, likes, and posts, the only way I can think for people to actually interact with the other would be to have the bridge be itself a server, so you would follow a bsky account by following @username@bridge.net which would then forward to @username which is super cumbersome
Seit letzter Woche braucht man keinen Invite-Code mehr um sich bei Bluesky anzumelden, die wesentlich spannendere Info steht aber, wie beiläufig erwähnt, im letzten Abschnitt:
This month, we’ll be rolling out an experimental early version of “federation,” or the feature that makes the network so open and customizable. On Bluesky, you’ll have the freedom to choose (and the right to leave) instead of being held to the whims of private companies or black box algorithms. And wherever you go, your friends and relationships can go with you.
Ich bin gespannt wie Bluesky federation umsetzen wird. Auf mich wirkt das ATProtocol immer noch viel zu kompliziert und „overengineered“, aber vielleicht ist das ja auch gerade der Vorteil gegenüber ActivityPub.
Ich hatte vorgestern einen kleinen Plausch mit @deadsuperhero für den Decentered Podcast, in wir unter anderem auch über die Schwierigkeiten bei der Implementierung von ActivityPub sprachen. Da WordPress in vielen verschiedenen Umgebungen laufen muss und sich die Konfiguration des Webservers, die PHP Version, das Caching, die Interferenz mit anderen Plugins und andere spezial Fälle nicht seht gut abschätzen lassen, ist es sehr schwer komplexere Funktionalitäten umzusetzen.
Ein Beispiel: Im Gegensatz zu OStatus, wo die Distribution von neuen Inhalten über PubSubHubbub (jetzt WebSub) geregelt wurde, ist bei ActivityPub der Service selbst dafür verantwortlich. Ein direktes Verteilen der Inhalte, direkt nach dem Veröffentlichen, würde bei großen Follower zahlen, den Prozess unnötig in die Länge ziehen, oder könnte sogar zu einem Fehler oder einem kompletten Abbruch führen. Um dem (so gut es geht) entgegen zu wirken, wird der Prozess asynchron über WP_Cron abgearbeitet. Leider ist aber auch das keineGarantie für einen fehlerfreien Ablauf (Siehe Ende des vorherigen Absatzes).
Lange Rede kurzer Sinn: Abhängig davon wie simpel ein Personal Data Server kurz PDS aufgebaut ist, könnte Bluesky vielleicht doch interessanter sein als ich ursprünglich angenommen habe.
i’ve been thinking about #ActivityPub and am going to use this as the start of an ad hoc thread about identity and account portability.
here’s where i think i’ll land:
1️⃣ the Conventional Wisdom conflates #Mastodon features with AP.
2️⃣ the Conventional Wisdom is that AP guarantees a #RightToExit, which it does not.
3️⃣🔥 and a hot take, as a treat: #ATProtocol is currently doing better work building the system that most AP advocates think is being built here.