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.

https://bsky.app/profile/ricci.io/post/3mooua5znk225

#bluesky #bsky #atproto #mastodon #fediverse #activitypub

Rob Ricci (@ricci.io)

ehhh... only sort of agree. The difference is that AP has a way to notify another instance if, say, there is a reply to a post, or a mention of a user. This scales down well. In atproto, since you can only write to your own repo, the only way to find replies is to observe the entire network.

Bluesky Social

https://overreacted.io/there-are-no-instances-in-atproto/

While having an extremely snobbish and arrogant tone, I think it makes some good points about separating hosting from viewing, which I think the usual #fediverse sort of conflates. And while the doesn't doesn't cover it, #atproto also has the unique feature of your data being relatively portable, largely absent in #fediverse.

#fediverse #atproto #bluesky #mastodon #lemmy #activitypub

There Are No Instances in atproto — overreacted

Like RSS and Google Reader.

On the other hand, the post largely glosses over the actual cost of running it, which Rob addresses above.

In fact, it entirely skips relays, which are so fundamental now, and in particular, that every #atproto app effectively needs to consume one.

(If your atproto app doesn't consume from a relay, it HAS an embedded relay, and in that case, god help your app's compute consumption).

#atproto #bluesky

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

FEP-ef61: Portable Objects - Fediverse Enhancement Proposals

Portable ActivityPub objects with server-independent IDs.

Hate to mention people out of the blue, but @ricci @cwebber if you can vet this info it'd be great. You two seem like the experts in these two topics, and I don't want to get stuff wrong. Thanks.

@innocentzero @cwebber

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:

https://bsky.app/profile/danabra.mov/post/3moovf2g2dk2u

https://bsky.app/profile/ricci.io/post/3moovkbywnc2t

Rob Ricci (@ricci.io)

Someone can visit my blog with an "app" that is self-hosted and ubiquitous: a web browser. Or, we can view the blog's backend DB + PHP/python/whatever as the complete app. Either way, I can set up a blog and people can read it with or without an RSS reader.

Bluesky Social

@innocentzero @cwebber One of the things I consistently see in these discussion is a conflation of "is cheap to run now" with "scales". This evening, when I pushed a bit more on this, the point that I got to is that people using and running this infrastructure don't seem to expect the network to grow a lot; they seem to think that it has basically reached the order of magnitude that it will be for the foreseeable future. I think this is a fine position to take, and I agree with them that things like relays and jetstreams will remain relatively affordable to run at even 10x the current network size.

But this is at odds with the more aggressive boosters who treat this as the way to build all social applications going forward.

If you think atproto will support a collection of applications that are, in aggregate, 10x the current size, sure, community infrastructure will continue to be cheap to run and the large amounts of data *someone* has to ingest for your small app or community is fine. If you think it will get to Twitter size (100x), I think you are probably wrong about this. If you think it will get to Facebook size, no way.

@ricci @innocentzero

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.

@cwebber @innocentzero @ricci

Somewhat related—on the relative moderation loads of a PDS owner and the owner of a Fedi instance.



RE: https://app.wafrn.net/fediverse/post/78e7e0d7-bd19-49ee-936d-7e5bb388c706
#ATProto #ATmosphere #Bluesky #ActivityPub #Fediverse #Mastodon

@dialecticalmusings @cwebber @innocentzero

I partially agree and partially disagree.

I agree that moderation load on fediverse instances can be high, and demonstrably leads to burn out. I think "the entire network" is overstating it; they only have to moderate the fraction of the network their users interact with. Which yes, can be a lot. But it scales linearly in the number of users, and one reason many folks tend to argue for relatively small instances.

What you get in return is the ability to create and maintain community standards.

Yes, you can run a PDS, in which case you are offloading almost all moderation to others. But you are just a data host. You cannot form a community with a PDS alone, and you are feeding that data into a service that must try to enforce some sort of global homogeneous notion of "community standards", which is the moderation scaling problem that many people are trying to avoid by using decentralized social networks.

If you want to form a community, with standards, you either need to run an appview, in which case you are truly moderating the *entire* network, not just the portion your users interact with; or you use the labeling tools available on eg. the Bluesky appview, which are cool but are not really good for community formation.

My recent conversations over on Bluesky have led me to the conclusion that, so far, people building on atproto tend (with exceptions) to think of themselves as building products, and people building on activitypub tend of thing of themselves as building communities. These are both fine, if that's what you want as a developer or user. The difference in moderation load comes from the fact that it's fundamentally different to bring your own data storage to someone else's product than it is to host a community. I think this is largely in line with what you are saying, but I think it's important to understand how different they are.

@ricci @dialecticalmusings @cwebber @innocentzero Plus it's completely possible to run one-user ActivityPub instances. I basically don't have to moderate anything there, and yet I host a number of my publications' accounts there which both post to and reply/boost others' content.

The "hard zone" is probably instances which have many dozens or a hundred+ users, requiring much more hands-on oversight but lacking financial resources. Under that or well over that, it's a different story.

@jaredwhite @dialecticalmusings @cwebber @innocentzero The author of the post we're commenting on - and, I think many other atproto developers and advocates - seem to not see the value in single-user instances because they think of Bluesky as "an app" or "a product" that only makes any sense as a whole, and not as a network where each node is valuable in its own right, there is value in controlling that node, and we build something larger by making choices on how to network. I think this is very un-web-like thinking, but it does have a certain logic if you think of it as a product and not a network.
@ricci @jaredwhite @dialecticalmusings @cwebber @innocentzero I encountered this prejudice when I was a moderator. Among the moderators! For them simply being a single user instance was straight up a black mark. Just one of the reasons I am no longer on that instance.

@jaredwhite @cwebber @innocentzero @ricci

As long as the single user-owner follows users on other instances, they are still responsible for moderating every post and every boost by those users. The load will obviously be far lower than that on a multi-user instance, but it will not be zero.

A PDS owner can also choose to be the sole user there. In that case, they simply have to ensure that they themselves post nothing illegal.

So my basic point still holds.

Agree with you that the moderation load will be particularly intense in case of large instances.


#ATProto #Bluesky #ActivityPub #Fediverse #Mastodon

@dialecticalmusings @jaredwhite @cwebber @innocentzero

> As long as the single user-owner follows users on other instances, they are still responsible for moderating every post and every boost by those users.

Only if they choose to expose a public "global" feed.

[edit: that is, the feed that shows everything seen by the server, not just posts made by the local user]

@cwebber @jaredwhite @innocentzero @ricci

Only if they choose to expose a public "global" feed.

Yup – agreed.

@dialecticalmusings @jaredwhite @innocentzero

I am currently working on a moderate issue on my instance regarding a reportedly-problematic instance that uses a language I don't speak and involving cultural nuances in a different country that are completely unfamiliar to me. This is, however, quite a rare situation. Normally, I have an easy time because the kinds of moderation issues that come up are ones encountered by people I have a lot of common context with, and that we have explicitly disallowed on our instance.

The atproto model described by the blog post - and specifically the Bluesky app/appview - simply cannot have this moderation context. If they have someone join who is hated/feared by trans users for the harm done by their rhetoric - toeing the ToS line but being careful not to cross it - then they "have" to allow that user on. I do not. I can deny them an account on my instance, block their account, block the instance they are on if it is a source of harassment for my users, etc. I am accountable to my users, I owe nothing to them.

@dialecticalmusings @cwebber @innocentzero @ricci Sorry, I'm not following. I'm not responsible for moderation of other users' content on their own instances if I'm the only user of my instance. There's no other user of my instance who would be expecting me to control what they are able to be exposed to.

@innocentzero @ricci @jaredwhite

In the ActivityPub world (and also the Nomad/Zot world), the posts by all users from other instances that you follow are pushed to your instance. In other words, those posts are stored on your own instance.

Suppose, for example, you start following me. Then your instance will pull in every post I make. If your instance exposes the public global feed, then a visitor can browse through my posts on your instance. They can search for specific posts by me there.

If I post something that’s illegal in your jurisdiction, then since that post will be publicly visible on your instance, you (as the owner) are liable.

@cwebber @innocentzero @ricci

I did say

… legally responsible for moderating the entire slice of the Fediverse visible to their instance.

so I am aware that a Fedi instance owner does not have to literally moderate the entire network. :-)

Why is the increase in moderation load (necessarily) linear though? Say, I am an instance owner, and a new user joins my instance. If she follows the conventional Fedi wisdom (“you are your own algorithm—follow a LOT of people and build a rich feed”) and immediately follows a lot of users from other instances, and if many of those users post a lot, and/or boost a lot, then all those posts will now land on my instance, and I am legally responsible for moderating them. Similarly, if my new user starts boosting a lot of posts from other instances, then I am responsible for moderating those too. So at least in this hypothetical example, the moderation load increases exponentially.

Of course, in case of an inactive user, the load may not increase at all.

I think the more important point is the uncertainty of not knowing what new stuff from other instances may suddenly start landing in your storage. (When I earlier said “more or less the entire network”, it’s this uncertainty that I had in mind.) Your existing user may start following some toxic person, and suddenly in comes the deluge. You may not have the bandwidth to look at some moderation report, and by the time you get round to it, the issue may have blown up.

In comparison, an admin/owner has a lot more authority and control over their own users, so there isn’t as much anxiety.

My only point was this: a PDS owner in the ATProto world does NOT have to moderate stuff originating on any other PDS. In the ActivityPub world, this option does not exist. To a lot of people, this difference matters.

By the way, you said:

If you want to form a community, with standards, you either need to run an appview, in which case you are truly moderating the entire network, not just the portion your users interact with …

I was under the impression that a PDS can directly communicate with another PDS without the need of an intermediary relay or AppView. Isn’t that correct? So couldn’t someone host a PDS + AppView (no relay), directly communicate with a small number of PDSs, and have their AppView show only those conversations? Wouldn’t this PDS + AppView setup be the equivalent of a Fedi instance? I could be wrong, but I believe wafrn does something like this on the ATProto end.

Regarding your broader argument:
I agree with you that moderation is a critical part of community building. (A corporate executive may say that in case of social media, moderation is the product.) I also know that moderation is a social + political + economic exercise, in addition to being a technical measure.

Personally, I think we need to urgently imagine what ought to be the political economy of social media. Is the Fediverse a public utility? If yes, who is providing the public utility? The state? Which state? Or some NGO? Some philanthropist? To whom is the public utility being provided?

Or is the Fediverse a market of commodities? If yes, who is selling those commodities? To whom?

One can ask similar questions about the ATmosphere. (The movers and shakers in that world seem to imagine it as a market of commodities, as you point out. But that may be just Americans on autopilot, there may be no deep thought behind it.)

The questions of moderation and community building are deeply entangled with the questions of political economy. People arguing about moderation and community building often have fundamentally differing visions for the political economy of the Fediverse, but those differences never get unpacked, so people end up talking past each other.


#ATProto #Bluesky #ActivityPub #Fediverse #Mastodon #wafrn
Wafrn, the social media that respects you

Wafrn is a social media inspired by tumblr that connects with the fediverse

app.wafrn.net
@dialecticalmusings @cwebber @innocentzero The reason it's linear is that if each user interacts with N other accounts, two users interact with 2N accounts, three with 3N accounts, and so on - this is linear scaling. Of course the Ns will be different for different users depending on their activity, and it's actually likely to be sub-linear since some of your local accounts are interacting with the same remote accounts, but this is the basic principle.

@cwebber @innocentzero @ricci

Ohhh, okay. I guess I was vaguely imagining the moderation load in terms of the increase in number of outside posts landing on an instance with the addition of each user. In other words, I was imagining that some edges connecting the nodes (users) could be very thick, and some very thin. Even then, one may simply measure and use average thickness of an edge, I suppose.

@dialecticalmusings @innocentzero

[Removing Christine from CC list as I think she expressed a disinterest in contributing to this thread.]

Sure, some links will be thicker in terms of, say, how many posts are passed back and forth between a pair of users. However, the thickness of that user-user link depends only on the activity of each of those users, not the total number of users. When we add up instance-instance links, by adding up the user-user links between those instances, this linear in the width of each of those user-user links (in fact it will contain duplicates, since two local users may follow the same remote user, etc.)

@innocentzero @ricci

Yes - thanks. I agree. I had simply not applied my mind enough when initially I thought the scaling may not be linear.

@dialecticalmusings @cwebber @innocentzero

> I was under the impression that a PDS can directly communicate with another PDS without the need of an intermediary relay or AppView. Isn’t that correct?

This is not correct from the "pure" atproto viewpoint. A PDS is simply a store of records, it has no user interface, it has only an API that users use to create and maintain their records (posts, etc.) and a streaming API for others to get copies of those records. The only visible interaction that users have with their PDS is the oauth login flow.

Think of it like an s3 bucket, if that is meaningful to you.

In this context, it makes no sense for PDSes to talk to each other.

Wafrn looks much more like the "instance" that the author of this article calls nonsensical in the atproto world, because it combines several things, including the store of many users' data including users who are not "local", the web interface and/or APIs that users access it with, and more. Wafrn does work in this world, but it is very much in opposition to the architecture the article at the root of this thread is claiming as the "correct" use and understanding of atproto.

@innocentzero @ricci

[Removed [at]cwebber, based on what you said elsewhere]

Yeah, my impression was incorrect. Looks like the Bluesky Jetstream is part of the picture, I think wafrn uses it to filter (using DID) only those posts/hashtags followed by its users.

@dialecticalmusings @innocentzero Despite my criticism of metaphor in the article, this is one way in which it's quite useful. It's easy to think of communication between, say, different wafrn instances over atproto, to be "inter PDS", but this is not how atproto views it, since they think of an "instance" as an "unnecessary" conflation of storage, identity, application, and unit of moderation.
@dialecticalmusings @innocentzero I've talked with gabbo a bit about this, and I think that wafrn instances do consume the entire jetstream for the bluesky lexicons, not just filtered for local users DIDs. While this seems highly inefficient to me, his position, if I understand it correctly, is that, at the current atproto network size, consuming a stream like this is fairly cheap, computationally, whereas all of the the one-by-one calls over https used by activitypub are more computationally expensive and slower.

@innocentzero @ricci

Hmmm - interesting.

I am unclear how this reflects in wafrn's public global feed. My impression is that the Bluesky posts there are only by Bluesky users followed by wafrn users. So some filtering must be happening somewhere, no? Or am I not asking the right question?

@dialecticalmusings @innocentzero I believe that wafrn is doing that filtering itself - it receives events from all bluesky users, discards those (most of them) that are not from users with local following.

@dialecticalmusings @cwebber @innocentzero

> Personally, I think we need to urgently imagine what ought to be the political economy of social media. Is the Fediverse a public utility? If yes, who is providing the public utility? The state? Which state? Or some NGO? Some philanthropist? To whom is the public utility being provided?

Strongly agree - the political economy used by atproto - as described in the blog post - is exactly the same one used by Twitter/X, Facebook, Instagram, and all of the other big tech companies. The "app" is a centralized thing, a product, that may have many stakeholders, but has one owner. Yes, they may provide you with some moderation tools Facebook doesn't give you, but at the end of the day, there is an owner of the app, and their moderation is enforced for all users of that app, regardless of what their PDS is on (Bluesky bans users from their appview, regardless of the user's PDS, for violations of their ToS). That is what you are outsourcing to when you run your own PDS but use their appview.

What is decentralized in the architecture shown in this blog post - which is the generally-agreed-on use of atproto - is *just* storage. This makes no appreciable difference to the political economy.

Now, both Blacksky and wafrn break this "typical" atproto architecture, in different ways. Blacksky does so by running a copy of (almost) the entire network (as well as other things like a more open governance process). In the blog author's diagram, it is basically another app, which happens to have functionality and network visibility that are very similar to the Bluesky app. wafrn breaks it more by building the "instance" that the author of the post doesn't think anyone should think of, combining the app and storage in a way that looks much more like the fediverse.

The fediverse (including wafrn here) provide the opportunity to experiment with fundamentally different political economies than the big tech companies have built. atproto (as understood by the author of this blog post, and as generally discussed) does not.

@innocentzero @ricci @cwebber

Within the boundaries for this thread indirectly set by Dan Abramov’s blog post, I agree with you.

I would argue that even in terms of data ownership, the argument of ATProto fans is not as robust as they imagine. All those narratives about data ownership talk about an individual “owning” his data, which obviously derives from today’s socioeconomic system imagining society as a collection of atomised individual consumers. So the ATProto narrative about PDS says that each individual user owns the record of their posts and their connections.

But in the real world, most digital data is meaningful and useful only within its larger social context. For example, if I can read this post alone ten years down the line, with no access to posts by others in this thread, then it won’t make much sense to me. Even for targeted advertisements, the data about an individual is only meaningful in the context of the social group the individual belongs to (“30-35 year old married woman with two kids, employed, spouse employed, stays in Berlin”). Same for policymakers looking at census/survey data.

So a Fedi instance actually pulling all the threads of conversations its users are involved in is a more meaningful design of “the instance as community” collectively owning that data. So far, so good. However, the legal setup in most countries does not even recognize a loose collective, let alone allow it to own and run an instance. That is without even getting into the questions of national (judicial) boundaries and the funds for running an instance. So most Fedi instances are run by high-earning technophiles. They remain dependent on the goodwill and mental bandwidth of the owner(s) and on donations by well-to-do users. Only the instance owner(s) own/control the data that belongs to the community. There is no design, even at the technical level, for the community to ditch the owner and migrate (together, as a community) to another instance. Overall, this model of a Fedi instance is very fragile at multiple levels. (I am not even getting into communities that cut across multiple instances.)

At the scale of multiple instances, we can immediately see that today this model is bound to remain limited to the Western world. Most of the countries in the global south do not have sufficient number of high-earning individuals (in proportion to their population sizes) who can also run Fedi instances. Neither do they have sufficient number of users who can pay/donate. (The tiny size of the Fedi indicates that even in the Western world, the number of individuals able and willing to run/support Fedi instances is very low.) So the Fedi is bound to remain a tiny white suburbia, with all of its accompanying pathologies (which further repel brown and black people from the West as well as from the global south).

(Stray thought: Maybe we should imagine instances analogous to public libraries + discussion rooms. In that case, we want administrators and moderators as paid employees answerable to the larger community, not themselves being “owners”. But even then, the question of a sustainable funding model remains.)

So… in the larger context, the enormous inequality across the world and between the global north/south is the core reason why most people cannot get out of free centralized social media services, even if they want to. That’s THE reason why Bluesky has a far larger user base than the Fedi, and why Instagram or Facebook have orders of magnitude larger user bases than even Bluesky.

Debates about the relative merits of ActivityPub and ATProto are no doubt useful, but they make no difference to this larger context. (This is not a criticism of your post, just a general point applicable to all such discussions. I am simply flagging the larger context, I have no easy solutions.)


#ATProto #Bluesky #ActivityPub #Fediverse #Mastodon

@dialecticalmusings @innocentzero

Yep, I agree with all of this! In particular I am concerned enough about

> the Fedi is bound to remain a tiny white suburbia, with all of its accompanying pathologies (which further repel brown and black people from the West as well as from the global south).

that I while ago I put out a call to hear from people running non-western or non-white instances, and as a result am a monthly contributor to a lot of these sorts of instances, and pay 100% of the bills for a small instance in the global south (administered not by me, but by themselves).

Despite the real and well-known problems with the Fediverse in this regard, I think it does offer a meaningful *possibility* for communities that are not well-to-do white tech folks to have and own their own communities and run them in a way that's consistent with their own culture and values. (I think it is, largely, failing at this so far.) At least, it has a clear path: create a small instance, invite others in your community to join this instance, if/when it grows it might get more expensive to run but hopefully that growth also means more resources to support it.

The atproto world described in the article does not, or at least it barely does. Yes, there are combinations of feeds, shared blocklists, labelers, etc. - so it's possible to say "join bluesky, follow these feeds, subscribe to these moderation labelers, subscribe to these blocklists" but this is not very clean. The closest existing model is Blacksky, which does automatically opt-people in to some of these things and foregrounds its curated feeds. Running Blacksky, however, takes a lot more money and technical ability than running a small instance in the fediverse. Blacksky, by the way, are very aware of this issue, and are building some stuff to try to make it easier to bootstrap small communities, though I have not followed this as closely and can't say much.

Our answer to "how do people from marginalized communities, the global south, impoverished areas, etc." form communities online has largely been "join the western (mostly US) tech companies' platforms". I think the atproto world is largely designed to replicate that structure, with the notable addition of some user-provided moderation tools (though these are largely features of bluesky, rather than atproto itself.) I think the Fediverse is *potentially* in a position to make a real change here, but it needs to start by changing the culture, which drives some people who do try away pretty quickly.

@ricci @dialecticalmusings @cwebber @innocentzero

What about we all run single-user servers, like #holos or something ?
No need to have moderation at scale, everyone is responsible for his own opinion and everyone can decide the people he wants to speak with.

My posts are public, if public means that everyone can potentially see them.
They won't be read by the whole world anyway

@arvind @Christine Lemmer-Webber @InnocentZero @Rob Ricci This, by the way, is why Hubzilla and its descendants have the pubstream deactivated by default, and why most owners of public servers refuse to turn it on.

Users are encouraged and empowered to moderate their own streams and contacts and given a variety of tools to do so, much unlike Mastodon that only gives you "mute", "block" and "call a moderator". But there simply is no realistic way for the admin to moderate the pubstream.

So the obvious solution is there not being a pubstream in the first place. Fortunately, the pubstream is optional, it's even off by default, and if it's on, it can be switched between what corresponds to Mastodon's local timeline and what corresponds to Mastodon's federated timeline.

Coincidentally, Hubzilla and its descendants are also the only fully nomadic Fediverse server applications and capable of things that aren't possible even with the AT protocol.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #PublicStream #Moderation
Netzgemeinde/Hubzilla

@[email protected] @innocentzero @ricci

Hubzilla, Streams, Forte and other Mike Macgirvin creations are indeed fascinating. So also the concept and the design of nomadic identity. Pity that there is so little uptake of his works.

(I also appreciate [at]silverpill's steady work towards incorporating some of MM's ideas into ActivityPub.)

However, it could be that the absence of public feeds makes it impossible for potential new users to get any idea of what Hubzilla (or Forte) is. So there's that tradeoff.

@ricci RE: "arrogant"

"Mastodon-brained"
"the Instance Brain"

Yeah, definitely arrogant.

@innocentzero @cwebber

@stefan

I've seen worse 🤷‍♂️

@innocentzero @ricci

Just had the most horrifying UX parsing this thread in Mastodon's microblog feed, likely causing 10x more network overhead than needed, and replied to @cwebber quote:

https://social.coop/@smallcircles/116792896530026124

Stepping away from ATProto vs. AP I was most intrigued by @dialecticalmusings comment:

> People arguing about moderation and community building often have fundamentally differing visions for the political economy of the Fediverse, but those differences never get unpacked, so people end up talking past each other.

What is never answered well is: What is fediverse? I'd argue it is just a common utility word like internet and web, denoting a communication medium.

What do you do with this medium is then the next question. Well, the power of ActivityPub allows us "to extend constructs of society online" to support our daily needs.

But on the basis of some warped microblog abstraction turned into a pretzel by bolting on features to hang everything off, this is not possible.

@innocentzero @ricci @cwebber @dialecticalmusings

If you take as the definition of social networking: Any direct and indirect human interaction between people.

And add ActivityPub in the full power of its conceptual architecture: A social graph of addressible actors that exchange activities with an object payload, fully extensible.

Then you have raw power to model about any online service where people interact with each other.

As part of my elaboration on Social experience design (SX) I coined "Personal social networking" as the exercise on how we can translate social networking practices we do for 1,000's of years offline, and think about how to seamlessly extend them with online support.

We talk so much how Moderation is essential, and there must be a Block and Suspend button etcetera.. but where do I have this offline in real social situations? Somehow social happens differently there. There's no moderator looking over my shoulder if I walk the streets of my town.

@innocentzero @ricci @cwebber @dialecticalmusings

Moderation is undoubtedly needed in many cases, but it is likely also done in many different ways and not a one-size-fits-all approach that moderates an overly complex microblog feed that no one can picture the intricate social dynamics that take place. A handful of basic app features aren't able to support that well. And yet we are trying to create that now. The current fediverse represents a lack of fantasy, where it is still Twitter what we have.

With a course correction of ActivityPub as a low-level communication protocol of building blocks and rules, what is build on top of it comes in the realm of Solution development. Carefully designed solutions to handle particular social settings and use cases. And where, if you want to have good interoperability, the business and application domains of these solutions also need to undergo good standardardization practices.

Getting there requires putting focus to the right places.

@smallcircles @innocentzero @ricci @cwebber @dialecticalmusings Off topic: Harassment happens in real life too and might have even graver consequences than the online kind for people. And usually in bigger cities somebody has a camera on you. Ostensibly laws and police should be protecting you but really ymmv quite a bit. Finally, inclusive and safe spaces don’t happen by accident but thru a concerted act of effort and design. And many people don’t even want these around.

@mojala @innocentzero @ricci @cwebber @dialecticalmusings

Yes, agree with all you say. I followed-up on that in the next toot. It is just that now we are inventing universal ways to do moderation, and that is just not a good fit as well.

We have a fediverse that represents an app environment that offers microblogging, an app domain. That is the technical implementation, the technosphere. Then we project all kinds of different modes of communication on top of that, that happen in different social contexts, with different audiences, purposes, and interests. The sociosphere.

We built a technosphere first, and then cram the sociosphere into it. That's the opposite to how it should be: tech should support people's needs, and be modeled accordingly.

There cannot be a concerted act of effort and design if the straitjacket of a microblog is already a given.

Take block/suspend. Ostracisation and silencing. Should be reserved for bad actors, yet get broader use that's really anti-social.

@smallcircles @innocentzero @ricci @cwebber @dialecticalmusings Yeah sorry didn’t see it before tooting! I do disagree on blocking though - I wish people did it way more and without qualms. I don’t think it would be anti-social unless taken to the utmost extreme.

@mojala @innocentzero @ricci @cwebber @dialecticalmusings

Blocking as an app feature constitutes a power tool: handle with care. If present then either good app design will guide its usage, or healthy social norms.

My observation is that on a fediverse that mashes all modes of communication together, and in a rushed society where everyone is dealing with severe info overload a kind of 'human laziness' creeps in, where social engagement as it would usually happen offline, is skipped and people liberally slam the block button.

I have had a few occasions where people I considered to be online friends, with years of communication history, suddenly blocked me and - after reading and rereading our comms - I didn't have the faintest clue why.

The block then makes it impossible to ask them "hey, did I offend you in any way?", and apologize. No human interaction possible. Not social. Inhumane.

In offline setting such situation nearly never happens. Walking past someone as if they are air.

@mojala @innocentzero @ricci @cwebber @dialecticalmusings

On one such occasion it was clearly the other person misreading, misinterpreting some text I typed, that led them to break all connections across multiple channels on a whim. Yet it took me 3 days trying to approach other people to convey that to them "hey, you were too hasty reader", to get things restored.

We talk about safe spaces and all that, and in terms of moderation - not seeing fascists and dorks on our timeline - this works well, if you're on a good instance. But the culture of our in-group that is being fostered, and is influenced by the feature set of the app, has a big influence too.

I found that on the surface there's a kind of happy joy joy we are all family vibe. But just below that there's a very harsh parasocial crust, and in any conversation you have to beware of all kinds of implicit no-no's or someone will be offended. I've mentioned that comms on the fedi is like walking through a minefield on eggshells.

@mojala @innocentzero @ricci @cwebber @dialecticalmusings

That is also inherent to how we design one universal communication space of sorts.

@InnocentZero FEP-ef61 all by itself isn't a magical solution. It's just one element in implementing full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) via ActivityPub, but it's far from being the only one.

See, nomadic identity wasn't invented just a few years ago or so, and it wasn't invented for, on and with ActivityPub either. It was first introduced in Fediverse software that works vastly, vastly different from Mastodon and from most of the rest of the Fediverse. I'm daily-driving what became of this software.

The beginning of nomadic identity: the Zot protocol, Red and Hubzilla


Nomadic identity was invented in 2011 by @Mike Macgirvin who had made Friendica (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica, https://joinfediverse.wiki/Friendica) as early as 2010. (Friendica is the oldest still existing Fediverse software, by the way.)

To put this into perspective: The concept of nomadic identity is over four years older than Mastodon. And it predates the first ActivityPub implementation by some six years. (Ironically, the software that first implemented ActivityPub is essentially the same software that first implemented nomadic identity.)

One issue that plagued Friendica is an issue that plagues everything decentralised: Servers shut down out of the blue, and users lose everything. That's why Mike had the idea to make identities not only portable (as in, easy to move from one server to another), but nomadic (as in, absolutely identical clones of the same identity exist on multiple independent servers at the same time, so if one server shuts down, you lose nothing).

Still in 2011, Mike designed a wholly new federated protocol named Zot to implement nomadic identity. Mind you, he had already designed a brand-new protocol from scratch for Friendica.

In 2012, Mike took his own Red, a development-grade fork of his own official development fork of Friendica. He pretty much ripped the whole backend out and also most of the frontend, and he basically developed an entirely new server application, now built against Zot. This was necessary because Red would have to handle identities completely differently from Friendica in order to make them nomadic.

See, Friendica handles identities just like Mastodon and almost the entire rest of the Fediverse: Your identity is your account, your login. You have one identity per login, you have one identity per server. All your data, all your stuff is stored directly in your account.

But you can't clone accounts. It's way too tedious to separate the stuff that must be cloned (contacts, messages, settings etc.) from the stuff that mustn't be cloned (login credentials).

So Mike created the concept of "channels" (https://joinfediverse.wiki/Channels_(Hubzilla_%26_(streams))). They're basically containers for your identity that contain everything except the login credentials on the servers. They can easily be cloned and moved as a whole.

Red still exists in a way: Later the same year, it was renamed the Red Matrix. And in 2015, it was completely refactored, it was greatly expanded in features and functionality, and it was renamed Hubzilla (https://hubzilla.org, https://en.wikipedia.org/wiki/Hubzilla, https://joinfediverse.wiki/Hubzilla). Hubzilla is where I'm commenting from right now, and this channel has been cloned for longer than most Mastodon users have known that Mastodon exists.

Nomadic identity via only ActivityPub: (streams), Mitra and forte


FEP-ef61 was created by @silverpill, developer of Mitra (https://codeberg.org/silverpill/mitra) in 2023. The goal was to take non-nomadic, account-equals-identity Mitra and make it every bit as nomadic as Hubzilla. Not by rewriting the entire backend against Zot (or its newest version known as Nomad) and then bolting ActivityPub support back on, but by using nothing but ActivityPub itself without rewriting the backend.

Development and sparrings partner became Mike Macgirvin himself who, at that time, was working on the streams repository (https://joinfediverse.wiki/(streams), https://codeberg.org/streams/streams), a Nomad-based fork of a fork of three forks of a fork (of a fork) of Hubzilla, somewhat slimmed down in features (it isn't a full-blown, jack-of-all-trades CMS unlike Hubzilla), but every bit as nomadic as Hubzilla.

The two worked out a way of using ActivityPub and only ActivityPub to establish nomadic identity. Not only to made Fediverse identifiers independent from servers, but to actually use ActivityPub to clone identities with everything attached to them between servers.

Eventually, FEP-ef61 was defined, and (streams) and Mitra became the first Fediverse server applications to understand portable identities as per FEP-ef61. (streams) was the first nomadic Fediverse server application to understand them, but it still uses its native Nomad protocol for its own nomadicity. Mitra, all by itself, still isn't nomadic to this day; it uses a client named Minimitra for nomadicity.

The first Fediverse server application that actually uses only ActivityPub for nomadicity, all the way to cloning and syncing channels, is Forte (https://codeberg.org/fortified/forte). It came to exist in mid-August 2024, essentially as a byproduct of an accident. (streams) had to juggle so many identities already, ActivityPub identities, Nomad identities, Zot6 identities, that when FEP-ef61 was merged into its release branch, it confused all these identities and didn't connect or federate with anything anymore. In order to find and fix the issue, Mike Macgirvin himself forked his own streams repository and ripped out any and all support for protocols that weren't ActivityPub. This required Forte to use ActivityPub for everything that (streams) used Nomad for.

Where we are now


So as of now, there are exactly three still existing server applications with full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity: Zot-based Hubzilla from 2012/2015, Nomad-based (streams) from 2021 and ActivityPub-based Forte from 2024.

There is only one of this kind that uses ActivityPub for everything, including nomadicity, and that's Forte.

Forte is the youngest member of the same software family as Hubzilla and (streams). They were all created by the same developer, and they were all born nomadic.

There is no case of a typical, classic, non-nomadic, account-equals-identity, ActivityPub-based Fediverse server application that was successfully converted to full-blown server-side clone/sync/move-entire-identities-without-leaving-dead-accounts-behind nomadicity. Forte itself wasn't converted from non-nomadic to nomadic; it was converted from Nomad-based to ActivityPub-based while having a nomadic legacy that dated back a dozen years at that point.

I'm not saying that it's impossible to turn non-nomadic software into fully nomadic software. But it's a huge undertaking that will require rewriting large parts of the server backend.

Essentially: You can't just add FEP-ef61 support to Mastodon and immediately clone your account over to other servers the same way that I can clone my Hubzilla channel.

CC: @Rob Ricci @Christine Lemmer-Webber

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Red #RedMatrix #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity
Nomadic identity - Join the Fediverse