Nice to see a blogpost on the Mastodon blog about implementing a basic ActivityPub server https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/
(Though technically webfinger isn't needed for activitypub, but it is for mastodon interop!)
@cwebber I'm curious how subscribing between different AP server implementations is going to work UX-wise. Mastodon, Pleroma and peertube all work with the user @ domain webfinger scheme, but what identifiers shall be used for implementations lacking webfinger?
Just search for https://toot.matereal.eu/users/schmittlauch instead of @schmittlauch.
@notclacke @schmittlauch @cwebber Honestly though, I've always liked the user@instance format that other federated networks use. It's a pretty useful way to think about users across the network; conceptually that identifier feels closer to email.
URL works okay, but the flow and the logic is kind of different.
@deadsuperhero @notclacke @schmittlauch yeah I get that, and people are fairly familiar with email-like ids. I'm not arguing against clients supporting that for composition of addressing anyway, but it does bother me that Mastodon uses Webfinger for some sources of information where it shouldn't matter for protocol'y things
I think that could hold back some exciting future things if it remains. But fortunately my suspicion is that it won't be hard for mastodon to evolve there.
@cwebber @deadsuperhero @notclacke @schmittlauch For the most part it seems to be based on the (mistaken) assumption that if users address each other by user@domain, then so should computers. But that's not really a valid or useful assumption... it's also already caused issues that have been solved in suboptimal ways (re: case sensitivity, account migration, username changes, etc)
@trwnh @cwebber @deadsuperhero @notclacke @schmittlauch I've been thinking for a while that I want to be able to use @strypey as my #fediverse identity, regardless of whether I'm self-hosting or using another host. The question is, what would be the equivalent of DNS that would resolve that ID to the underlying host-based ID (eg currently mastodon.nzoss.nz/@strypey)? How would I update it when I move hosts? How do I secure it against hijack?
@strypey @trwnh @deadsuperhero @notclacke @schmittlauch This is what DIDs are trying to solve
@cwebber @trwnh @deadsuperhero @notclacke @schmittlauch cool. Two questions 1) what does DID stand for? 2) Where can I found out more?
@strypey @trwnh @deadsuperhero @notclacke @schmittlauch Decentralized Identifiers. Look up various Rebooting Web of Trust papers and the w3c spec. DIDs aren't human readable, but you'll have a unique identifier for yourself for life. For the human readability, add petnames. https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md
@cwebber @trwnh @deadsuperhero @notclacke @schmittlauch so my actual ID might be a string numbers like an IP address (or alpha-numeric or whatever), but I can associate @strypey with that in all my apps, and users who connect with me can decide whether to nickname me @strypey or use their own preferred nickname (@irritatingcleverclogs or whatever). Yes?
@strypey @cwebber @trwnh @notclacke @schmittlauch Why do we want this to be a thing? It just sounds like extra complexity for a vague notion of flexibility.
@deadsuperhero @cwebber @trwnh @notclacke @schmittlauch the obvious benefit to me is that it makes my actual ID unique and portable between instances and apps, and it does it without forcing users to try to interact with IDs like "user:789345h89hkjsfksdh"
@trwnh @deadsuperhero @cwebber @notclacke @schmittlauch good to see you here @macgirvin ! Would be great if there was a way to bring something like #NomadicIdentity and #ChannelCloning into AP, or a future replacement for it, and even better if it could be fully compatible with the way #Zot does it :)
@strypey @trwnh @deadsuperhero @notclacke @schmittlauch @macgirvin
> one can potentially connect with me by using webfinger for any previous acct: or https: identifier I've had - using any server in the network that has historical knowledge of that identifier.
I'm still concerned about this aspect of Zot nomadic ids. If you're relying on a mutable naming scheme like DNS, if I say "oh yeah, I really used to have this post over at foobar.example", how's a new server to know if that's really true?
@notclacke @macgirvin @schmittlauch @deadsuperhero @trwnh @strypey Yeah the nomadic id is canonical (which really boils down to: the public key fingerprint is canonical)
If Alyssa used to be https://foobar.example/@alyssa but moves to a new server, and Mallet was never on foobar.example but claims they were https://foobar.example/@alyssa, if Ben shows up on the network later, how is Ben to know that Mallet's posts that claim they were on alyssa's old foobar account weren't hers?
@notclacke @macgirvin @schmittlauch @deadsuperhero @trwnh @strypey Another problem that must be addressed when the key fingerprint is effectively the "true id" of a user is: what about the fact that ciphers weaken over time? Surely I don't want to be bound to my old RSA 1024 key for life.
@bob @cwebber @strypey @deadsuperhero @schmittlauch @macgirvin @notclacke IIRC doesn't Zot use a separate 256-bit UID in addition to a public key? That solves both issues, but wouldn't old posts need to be "reclaimed" somehow when the public key changes to something more secure? I assume it's easier to "invalidate" them instead.
@cwebber
This is where some kind of append-only database with timestamp oracles (total ordering is not necessary) comes in. Have some kind of key superceding scheme, then always look up the earliest instance and follow it to the latest key.
@strypey @trwnh @deadsuperhero @schmittlauch @macgirvin @notclacke
@notclacke @macgirvin @schmittlauch @deadsuperhero @trwnh @strypey @cwebber
PGP lets you revoke a key as superseded, but there need to be witnesses along with a way of saying what the new key is.
@freakazoid @strypey @trwnh @deadsuperhero @schmittlauch @macgirvin @notclacke You just described DIDs :)
@freakazoid @strypey @trwnh @deadsuperhero @schmittlauch @macgirvin @notclacke Except that DIDs let you do something that PGP keys don't: have the *same* abstract id that can be carried forward to your new key.
> I'm still concerned about this aspect of Zot nomadic ids. If you're relying on a mutable naming scheme like DNS
The whole point of nomadic identity is that you aren't relying on DNS.
@macgirvin @trwnh @deadsuperhero @notclacke @schmittlauch sure, but that doesn't answer @cwebber 's concerns. How does #Zot deal with:
> if I say "oh yeah, I really used to have this post over at foobar.example", how's a new server to know if that's really true?
If one presumes that the validity of a post is dependent on what website it is posted on, they aren't really understanding nomadic identity. Content is linked to nomadic authors, not the websites they may or may not be using at some point in time.
@macgirvin @deadsuperhero @cwebber @notclacke @schmittlauch @strypey Mike, the concern seems to be not about validity, but about provenance of that nomadic author.
@trwnh @macgirvin @deadsuperhero @notclacke @schmittlauch @strypey Yes... it seems to me that Zot Nomadic Identity is trying to have its cake and eat it too on both "it's not tied to a uri so it can live anywhere" but also "it still holds the old uri's history there" (even if dead). I'd suggest dropping the old uri history, since that won't survive transfer on the network. Go full on content-addressed.
@deadsuperhero @strypey @notclacke It's not really extra complexity, it's different complexity, with different tradeoffs, and I think the tradeoffs are worth it.
I should probably do a writeup explaining in more detail. I'm still in the middle of unpacking boxes so I don't think I'll be sufficiently coherent to explain.