interesting read in defense of Nostr's architecture.

[liaizon@social.wake.st]

RE: https://toot.community/@dyne/116018338049205915

interesting read in defense of Nostr's architecture. really seems like there is a renewed battle between ATproto, ActivityPub and Nostr lately

[liaizon@social.wake.st]

(don't worry I am still on team fediverse) though we realllllly need to decouple our identity systems with our hosting and indexing

[setto@tooting.ch]

@liaizon ATpoopoo's marketing agents be like "yes, we are the same!"

[nextgraph@fosstodon.org]

@liaizon and this can be done with @nextgraph and @activitypods

[liaizon@social.wake.st]

for it to actually work for the fediverse we would need it to be done in standardized protocol driven way along the lines of what @silverpill is working with their FEP. Saying you can do it with @nextgraph + @activitypods is missing the part where it needs to be done in a way that hundreds of different code bases in different languages can implement and interoperate with the new way of addressing

[d6@merveilles.town]

@liaizon it's very interesting to me that the author here considers federation to be entirely a downside.

as far as local community, moderation, sharing costs, etc having an opinionated instance (versus transparent relays) seems pretty important to me. i strongly prefer _not_ being totally independent.

(that said i agree that we really need some kind of portable identity/history support on the fediverse to enable better migrations)

[nextgraph@fosstodon.org]

@liaizon @silverpill @activitypods Yes I know. Silverpill knows me and my work a bit, and I would like to discuss it with all of you. we have solutions of DID in ActivityPub, and also for an easy way to build social apps on top of it, similar to what Lexicon and PDS does, in the ATproto world. Would love to starting working on a FEP about that

[liaizon@social.wake.st]

@d6 I think it really depends on what your history of how you were using the network. I think a lot of people got dumped on many random instances and then basically had random admins that were into hosting stuff as their overlords. if you are on an instance that is actually set up and treated like its own community you end up having a very different view of what the network dynamics are

[liaizon@social.wake.st]

@nextgraph @silverpill would love to see it! getting some of the stuff you are already trying to do with @activitypods written up in FEPs and generalized so that other implementations could start to play with it would be amazing.

[d6@merveilles.town]

@liaizon that's fair. i did start on mastodon.social (classic "random instance" instance) but moved once i got a chance.

[kris@outmo.de]

@liaizon Reads a bit like a fan letter about an Ayn Rand book, and makes about as much sense 😅

[nextgraph@fosstodon.org]

@silverpill @liaizon @activitypods This FEP-ef61 looks great!
It is most probably the only solution for the standard that will bring interop.
What we have at nextgraph+activitypods is an implementation of a DID that works for AP (it will be ready very soon).
I need to read the FEP and then let's discuss it. I've curious to hear your ake on all previous attempts on the subject. Of course DIDs should not be mandatory. About `did:key` we have to see if it is really needed, I am all ears on that

[reiver@mastodon.social]

@liaizon

The are many good things about Nostr. And, there are things the Fediverse can learn from Nostr.

Although technically, the Fediverae COULD already work a lot more like Nostr.

More recently @HolosSocial has been doing just that — by going in that direction.

[oblomov@sociale.network]

@liaizon when I first looked into nostr, I thought it had an interesting architecture, which was a completely moot point on a network completely overrun by cryptogrifters