silverpill
That article about Decentralized Identity in AP is a bit outdated and doesn't mention FEP-ae97: Client-side activity signing. This FEP describes a system that is conceptually similar to Nostr and SSB: clients control the keys, all messages are signed, servers distribute the messages.
Nostr keys should be compatible with it, and maybe ATProto identities too (we rely on the same DID standard).
I am currently developing a server and a client implementations in Rust.
Light
@adam Interesting. Can you elaborate on that a bit?
Also, have you heard of @silverpill and @arcanicanis's work on native sovereign identity on the fediverse?
https://arcanican.is/primer/ap-decentralization.php
Adam Nelson
@light I've heard of it but hadn't looked deeply into it before. Looks like it has potential---in fact, it might be possible to use a Nostr secp256k1 key as a did:key and share the same public key between the Nostr and AP versions of an account!
As for my Nostr idea, maybe this explanation is clearer:
Currently in Nostr, users are identified by pubkeys and optionally NIP-05 URLs, and they use relays to share events, and the users and relays have no relationship to each other.
What I'm envisioning is a part of the Nostr network (compatible with the rest of the network) where users belong to instances, like ActivityPub. Each instance has its own relay. All members of an instance have a NIP-05 URL on that instance and publish posts to that instance's relay.
The instances then federate with each other, following the same model as Mastodon: every time a user on an instance follows another user, the instance federates with the other user's instance (by connecting to its relay) and receives all of that user's posts.
If you read from an instance's relay, you get the same subset of the network that you would get on a Mastodon instance's federated feed: all users on that instance and everyone they follow or interact with.
But, since this is Nostr and everything is signed, it also provides censorship resistance and credible exit. If your instance goes down or bans you, you can not only move to another instance with the same pubkey, but also collect all of your signed posts from your followers' relays and reconstruct your entire account!
This also solves what I consider the biggest UX problem of Nostr: relays are even more opaque and confusing than instances, because they're not communities and it's not clear which ones you should join and why, how long they'll be around, etc.
Adam Nelson
@light Part of the plan is to "extend" Nostr with a concept of home servers like Mastodon, where your account lives on a specific server and uses that server as a relay, and servers federate with each other using those relays, so your posts are accessible on the relays of anyone who follows you.
It has the advantages of both Mastodon (instance communities, better spam protection by allowing instance blocks) and Nostr (censorship-proofing because your account and posts will survive a ban or server deletion).
Adam Nelson
@light It's a long-dormant project that's been through a few (unpublished) rewrites.
The most recent revision is written in Scala, still planned to have most of the same features, but as a 3-protocol Nostr/AT/AP server with Nostr as the default protocol and federation method. But I've been bouncing between projects so much, it'll probably be a while before it's ready.
Also it probably won't be called Tapir anymore because there's a popular Scala REST library called Tapir.
Light
@adam
>3-protocol Nostr/AT/AP
That would be cool as well. makes me think of https://micro.blog/ which is partway there.
Light
https://github.com/ar-nelson/tapir?tab=readme-ov-file
These features look cool.
h/t @adam
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.