Untitled attachment

Notices where this attachment appears

1. arcanicanis (arcanicanis@were.social)'s status on Sunday, 11-Feb-2024 18:46:18 JST arcanicanis

   in reply to

   I mean, HTTP Signatures wasn’t very hard to implement and get working fine and interoperable with other fedi software, and I’ve read portions of the [draft] spec, it’s just not anything usable as a format of portable data that could be relayed between servers. You just also have to check with implementations of what headers they expect to be signed, which is part of the unwritten rules in fedi that you’re not going to find in the HTTP Signatures spec itself.

   But if you want to find endless rabbit holes of practically “protocol mills” (if that’s an appropriate moniker?), just dig into some of the distant depths of the Verifiable Credentials suite of standards, or for insane extremes, go through the labyrinth of specs for Solid: https://solidproject.org/TR/

   Apparently they even define their own system of HTTP Signatures: https://solid.github.io/httpsig/

   depend on the N3 language for manipulating data: https://solidproject.org/TR/protocol#n3-patch-example

   https://w3c.github.io/N3/spec/

   But outside of the topic of Solid, and as mentioned earlier: at least some parts of Verifiable Credentials can be borrowed into fedi, and narrowly implemented for a specific opinionated use, such as object signatures, as I’ve described in: https://arcanican.is/primer/ap-decentralization.php

   But yes, there’s just insane degrees and extents in which people just keep dreaming up new standards, and making things unfathomably more complex than needed, likely just to sell consultancy and to pitch more VC startups.