My idea is the .xml file is read it as a simple string. The host or feed builder would minify the string using a standardized function (this helps to remove extra spaces, new lines, etc that would create a different hash), then hashes it, signs the hash, then add that signature to the xml file.
Adding the signature to the file of course breaks the hash.
So to verify, an app would first remove the signature from the xml file, then minify the string using the same function the host did, then hash then hash it. The string should match the string that was originally hashed because the signature was removed first, and the hashes should match.
And yes, there would have a specific tag to add and remove to ensure nothing extra was added, but as long as everyone was using the same inserting and removal functions, that 'should' guarantee consistency across multiple apps and hosts.
The other would be a function that every app and host uses that parses the xml to a json file, remove the signature tag from the json file, then hash the JSON.stringified object, sign that hash, add it back to the JSON signature tag, then convert back to xml. As long as there's a consistent way to remove the signature before hashing, I think it would work.
Now, I don't think there's a way around preventing piracy, that is someone from taking your feed, changing the value block and npub to their own, and signing it and posting it on their server.
There's never been a way to prevent that, and I'm not sure signatures can, any more than they can stop either of us from signing a note that says "I rock" and claiming to be the original author. But signatures can definitely help with the problem of redundancy and ensuring the feed hasn't been tampered with.
Here's a proof of concept that allows storing a signed hash in the feed.
https://svelte.dev/playground/134809f1af4d4651a35516502432cf3b?version=5.20.2
If you're on the backup server's approved npub list, they can store it for you for redundancy, otherwise they can reject the feed.
The app can then fetch the feed and verify the hash against the feed.
If the redundant server acted maliciously and modified the feed prior to storing it, like in the Stolen Feed example in which the value address changes, then the app would flag it as an unauthorized change and fetch the feed from the next server in the redundancy list.
Thread collapsed
Thread collapsed
