I've started putting together a list of apps, focused on implementations of , documenting their status and what tech stack they're (being) built with: ethercalc.org/fediverse-stacks

This is a publicly editable doc, so would appreciate corrections/additions, and feedback especially from fediverse devs, but also from instance admins and users:

- What app/implementation/stack did you try?
- Pros/cons you encountered
- What stack & libraries would you choose if starting today?

PS. We've been talking with @bhaugen and others about the need for a generic agent-centric server, so that instead of signing up to a bunch of different servers, a user could have their indentity and data all in one place, and all the apps they use (clients, but if necessary server-side "plugins" as well) would interact with the activity/objects types that they support.

What do you think?

cc @cwebber @aaronpk @deadsuperhero @aral

Show thread

@mayel @aral @deadsuperhero @aaronpk @cwebber @bhaugen

wouldn't this cause bottlenecks in the network? Like: imagine your identity is stored on a server that goes down when you most need it. Could this be mitigated by some form of cross-server data propagation/mirroring, just like different torrent trackers can index the same torrent file?


@Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel

> imagine your identity is stored on a server that goes down when you most need it.

1. That's a problem in any radically decentralized architecture. SSB handles it by gossip replication and resyncing, that is tolerating offline situations.
2. Can also happen in a federated architecture like Mastadon where your identity is stored on one server with a bunch of others. That server can also do down.

@bhaugen @mayel @aral @deadsuperhero @aaronpk @cwebber

> That server can also do down

- it sure can, but social.coop going down will not affect any other instance. But what happens if a hypothetical identity.social service holding the identities of thousands of users across the whole fediverse goes down? I'm not being negative, I'm just curious :)

caps lock 

@Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel

Now (just talking and thinking stage) is the best time to be negative.

> a hypothetical identity.social service holding the identities of thousands of users

That's not what I am thinking about, anyway. I'm thinking about combos of people who host their own identity and community-oriented servers that might host identities for community members who do not want to host their own.

@mayel @aral @deadsuperhero @aaronpk @cwebber @Antanicus

So not that different from the fediverse that exists, and compatible with the fediverse that exists.

@Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel

When I looked at Pleroma instances, I saw a lot of single-person self-hosted sites.

@bhaugen @Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel I'm not interested in identity (singular), controlling it or otherwise. But I do want to build tech that protects personhood and however many identities we decide to have :)

@aral @mayel @deadsuperhero @aaronpk @cwebber @Antanicus

We're also good with multiple identites, but if we want to have one identity and use it in lots of AP contexts, we want to be able to do that. And we are definitely looking for a P2P architecture.

@Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel @bhaugen No different than social.coop going down. A generic AP server would host the Actors and their posts snd followings. Unless you had client-side caching like an email client, you will lose access to your data, and you certainly can't send/receive.

Then distributed copies(like IPFS or DAT do) of the database are the only way...

@bhaugen @mayel @aral @deadsuperhero @aaronpk @cwebber

@Antanicus @bhaugen Not necessarily. That would be a distributed system as opposed to a federated one. ActivityPub is not meant to be a database in itself, it's a traversable graph that can be converted to a local database.

You could have a DHT that resolves to a changing URL, but that doesn't really address availability of the content by itself. You'd need a replication strategy like primary/secondary, and then point to URLs so that they can be tried in-order. Out-of-scope with current AP spec

@bhaugen @Antanicus @cwebber @aaronpk @deadsuperhero @aral @mayel That's why you have an always-on node. I'm exploring the use of DAT for that. See ar.al for posts on Web+ and a step in that direction.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!