Mastodon's federation introduces UX challenges.
One that worries me a lot is about message forgery. Anyone can forge a twoot, even cross-server.
Whereas Twitter Inc might be trustworthy enough to not forge transcripts. Anyone can run a Mastodon server and might want to abuse it to influence people (see Russian troll campaigns).
Should Mastodon "home servers" cryptographically sign updates? Should there be end-to-end signatures? Anyone has thoughts on this?
@fj Verifying messages is important / critical in a federated network. In ActivityPub it's required to technically conform to the standard, though how you do it is somewhat looser; eg if you "share" a message, and that message is embedded and comes from a different origin, the most minimalist approach is to check the source and make sure it matches.
But signatures are better... [... contd ...]
@fj The "right" way to do it is definitely to sign messages as you pass them along the network. We include a section for this using Linked Data Signatures and HTTP Signatures https://www.w3.org/TR/activitypub/#authorization-lds
Unfortunately, it's non-normative. The specs need more use and "proof in implementation" before they can become the de-facto way. It would have been way better to make it the definitive way to do it (but at least a method is presented)
Btw @mikegerwitz you might appreciate this article, "An even more distributed ActivityPub" http://dustycloud.org/blog/an-even-more-distributed-activitypub/
@mikegerwitz One more thing along "even more distributed": it *should* be possible to use ActivityPub on a more peer to peer / distributed system than HTTP. Luckily URIs can have different schemas... so you could handle a different network layer there. The one thing you'll still need is HTTP GET/POST to comply w/ AP.
The fastest route to thinking about what that might look like is to think about using Tor .onion addresses; but there are better examples possible.
@bob @mikegerwitz I don't know anything about ZeroNet but it looks cool.
@mikegerwitz It's out of scope for current work of the SocialWG, but maybe something that will be explored in the follow-up Community Group. Focusing on making the web we have be better federated is the current goal obviously... but we can do even better, with surprisingly few changes and I believe backwards compatible changes. (But maybe not forwards compatible, as in nodes that don't understand the p2p uri schemas might not know what's going on).