protocol VS fedbox

We have already have a clear stack. there's Gitcoin Passport for sybil resistance, git (and wrappers like Radicle) for version control, Lit PKPs & Gelato for account abstraction, Farcaster/Orbis/Lens for social architecture, OpenStreetMaps for geographic markets, OPStack, etc.

These services exist outside of the protocol and depend on a few centralized and trusted authorities.

Another solution that is arguably more resistant to capture and censorship would be to use a blockchain to manage user name aliases - like Farcaster is doing with fnames.[1]

[1] https://github.com/farcasterxyz/protocol#22-farcaster-names

one XMPP server gets big and usernames get squatted and dealt with at the discretion of the server admin.

Only solution is something like how Farcaster does it

https://github.com/farcasterxyz/protocol#3-identity

That's sad to hear, but it makes total sense to shut down the server given its sensitive data, rather than hand it off to another person.

Mastodon/ActivityPub is a poor fit for a social network IMHO.

- Accounts should not be tied a single server and their continued maintenance.

- Private data and DMs should be end-to-end encrypted rather than entrusted with a single administrator.

- People don't want to self-host.

The core problem of a lot of social networks comes down to name aliasing, and who controls the name registry. In the case of nostr[1] this is not a problem because everything is using public keys. Another protocol is Farcaster[2] which plans to use a smart contract to maintain a name registry without requiring a single controller.

[1] https://github.com/nostr-protocol/nostr

[2] https://github.com/farcasterxyz/protocol

If you're interested in an ActivityPub that works like that, I work on one called FedBOX[1]. It doesn't have clients at the moment, but that's how I planned to have it used.

https://github.com/go-ap/fedbox

Well, there is one already as the reference implementation for a suite of libraries I wrote. You can find it at https://github.com/go-ap/fedbox. (Contributions welcome)

Also my project, mentioned elsewhere in the thread: https://github.com/go-ap/fedbox, supports filesystem storage directly.

Hi, I'm the developer of go-ap. Which parts of it are giving you trouble? I'm always open to answer questions to the project's mailing list: https://lists.sr.ht/~mariusor/activitypub-go

There is a rather hidden wiki that has some more information than strictly the comments in the code: https://man.sr.ht/~mariusor/go-activitypub/

If you are looking for examples, there is a reference server at https://github.com/go-ap/fedbox

There is a Go implementation of a generic ActivityPub service. I am actively working on it as we speak: https://github.com/go-ap/fedbox. (You can see a demo instance of it at https://federated.id)

That's pretty cool actually. I've been tossing around the idea of a federating forum style UX that uses ActivityPub, and I figured it would be easy using something like this https://github.com/go-ap/fedbox

I don't know how many generic AP backend servers are out there, but it looks like Lemmy is becoming one. I hope they keep with the AP spec and allow any functionality in addition to it to be modular.

> What we really need in this landscape is dead simple services.

I'm working on exactly that: a service that acts as an ActivityPub server (code[1], example[2], example application running on top of it[3]) for users in the form of a static binary. It supports multiple storage backends that can be selected individually or all together at build time and it can be extended to many more.

[1] https://github.com/go-ap/fedbox

[2] https://federated.id

[3] https://littr.me