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

@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 :)

@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.

Antanicus
Follow

@trwnh
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

Sign in to participate in the conversation
social.coop

social.coop is a a coop-run corner of the fediverse, a cooperative and transparent approach to operating a social platform. We are currently closed to new memberships while we improve our internal processes and policies, and plan to re-open to new folks when that work is complete. [9/2/2018]