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?
@notclacke @schmittlauch @cwebber to clarify—while URIs are used in a lot of scenarios, including all federation references, for practical reasons mastodon uses webfinger as its source-of-truth for account uniqueness. we also require that other implementations we federate with have it for UX reasons
@notclacke @nightpool @schmittlauch Yes, I suspect/hope as the AP network grows, reliance on webfinger will decrease, including its current use in role of what shouldn't really apply for some federation stuff
@cwebber @notclacke @schmittlauch right now the main issue we had with URIs was their fragility—people switching between http/https and people switching between pleroma and mastodon were two major practical issues we ran into a lot that led us to privileging webfinger over URIs.
the second reason is ideological. Mastodon is microblogging, which means (to us) that posts are plain, not rich text. if actors exist in the network that can't be @-mentioned, then that's a huge user expectation problem
@nightpool @notclacke @schmittlauch I understand the frustration with http and https. Have you ever seen Tim Berners-Lee's "Web Security - TLS Everywhere, not https: URIs"?
https://www.w3.org/DesignIssues/Security-NotTheS.html
His argument is, of course we should have a cryptographic layer, but we shouldn't have two different uri schemes for the same resource served as unencrypted/encrypted... instead, there should be one uri scheme, and the encryption selection bit should be a protocol negotiation concern. I 100% agree.
@nightpool what problems of mutability?
@nightpool http(s) has problems with mutability all around anyway :)