allow me to criticize the state of the fediverse as much as love it:
- tiny brain: mega-node such as mastodon.social oh dang it we've reinvented twitter
- regular brain: I'll just choose an instance off of joinmastodon.org oh dang it got shut down everything I love is lost
- galaxy brain: I'll self host fedi software oh god this is hard I'm afraid to upgrade
- universe brain: we need to merge the fediverse with p2p network designs so a node going down isn't catastrophic
btw, some of the "gaps" that were left in the activitypub spec were intentionally there to enable this to exist https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/activitypub-decentralized-distributed.md
for example "why didn't activitypub require https as the only valid uri scheme / protocol"
well, the solution to the "content surviving when nodes go down" may rely on the fact that this was left open: https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/magenc.md
@cwebber that was a good idea. I still think we should be using IPFS for static file distribution. and it looks like we can
lots and lots of neg ranting
@cwebber tbh i've gotten kinda disillusioned/burned out with activitypub, sinoce there's currently only one or two real implementations that use a proper graph as store and everything else only uses activitypub as a transport between nodes. And there probably won't ever be more.
The biggest issue is that any optional features in the spec will basically be guaranteed to not become common enough.
Being able to use JSON-LD to parse it is nice, except that all servers basically expect a subset of what compacted JSON-LD produces verses manual written JSON (this causes. issues). And this is unlikely to change ever. Because each piece of software uses their own internal repr, you can basically guarantee inter-instance migrations will never work (clashing IDs, etc). And obviously, this causes security issues. Never mind that we kinda didn't spec out authentication and both mainline auth techs have large gaping holes in their security if you look close enough. (so far Kroeg is the only one that has preemptively avoided every single origin, request, and id mismatch that i have encountered)
The solution to this? basically design the spec in such a way that there's only one "method" to things. Of course, you can keep flexibility, but one easy way is: have the object ID contain the hash. Now the object must be stored as its original representation.
Another opinion i have built up is to maaaaybe limit exact structures of objects just a litttttle bit. OrderedCollection being able to contain orderedItems vs being required to contain a page is... not great.
lots and lots of neg ranting
@cwebber the as-of-yet unnamed and unreleased protocol I'm building as an experiment vill contain e2e encrypted everything basicaly. Park your data on a homeserver (closest equiv to instance will store data and forward messages for you if you so desire). Or run the entire thing over ephemeral tor hidden services that can't be located unless you physically exchange a pair of keys. Private messages are 100% private and repudiable (think Signal), while public messages are cheap and can be encrypted to large groups of members efficiently. At least, that's the plan. But from what I've worked out so far, this should be doable.
lots and lots of neg ranting
@puckipedia re: content addressed objects, completely agree
Lots of other things in your post that I think I agree with as well :)
I think AP is more "salvageable" than your post seems to think it is but that's not my primary concern at the moment (and I agree that much is hindsight). You mentioned you're thinking about all of this and I have one request: write those things up!
@puckipedia @cwebber I don't know much about these topics (other than that I love federation and love P2P even more), but while I'm sure these are some excellent developments I do want to drop off this comic as a gentle reminder
Maybe working to improve ssb and/or ActivityPub, rather than replace them, could have the same results?
@cwebber @puckipedia The great thing about both standards is it's a LOT easier to get people to switch over, because they're still part of the same network. I'd totally be open to a p2p-fedi hybrid if it means I can still follow my mastocrew
So I think leading the way with a new platform is totally viable. Much more so than asking people to take a risk with a competing standard
@socalledunitedstates @cwebber I mean, I've been there for quite a bit of the ride. I do still think an AP based p2p protocol is possible, but it won't be as great an experience as it could be. And part of it is, if someone releases p2p for ap, it'll take a while and more work for others to implement than just plain ActivityPub, and my guess is that most people won't care and end up writing only the HTTP parts, ensuring adoption of p2p AP can't really happen at all.
lots o text
@cwebber @socalledunitedstates ssb's flaws are not really fixable (can't really change the signature algo to make it easier to use, because old sigs will still be around). AP, while nice in some ways, has other design flaws I should've realised long ago (I can make a post that both Mastodon and Pleroma trip over, both in different ways though). Salvaging AP for my protocol would end up being ... not great, as now you're probably dependant on basically specifying every single activitypub attribute, multiplicity, and where it may occur. Which kinda defeats the purpose of it being based around a linked data platform. I will also drop JSON from my proto, as it's bulky, annoying to parse, and has too many variables to consistently serialize. Note that the replacement will still be linked data, just not JSON-LD (or RDF)
@elplatt it's hard for me to evaluate freenet as a feasible thing even though I've read some of the papers since there seems to only be one serious implementation and it's this java thing I don't understand, and I can't figure out how to compose the components
Otoh even though there's also only basically one Tor implementation, I can figure out how to compose it together with other tools
@cwebber There are a couple local developers I know from cryptoparties and Penguicon. Small but smart and dedicated community.
It's totally a "rough consensus and running code" kind of standard, but the community is super approachable.
@cwebber I don't agree with the comparison of large federating nodes to twitter. Twitter doesn't federate - it's a walled garden. mastodon.social is not, and neither are any of the other large federating nodes.
@cwebber the idea that everyone should self-host or join a small community is utopia. Most people just need a service.
@cwebber What existing work is there on merging fediverse with P2P networks?
I actually want to work on hashtag federation, utilizing a DHT for responsibility assignment. But this won't solve your nomadic identities/ redundancy issue.
@cwebber I'm with you on the p2p thing here. I was also on two Mastodon instances that shut down and hosted my own instance of Pleroma, which was fun, but got squeezed out with everything else going on.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!