Hacker News Reader

Comment by jkarni | Hacker News Reader

While it's true there's currently no easy way to do that, we've made the machines (the name we use for each instance of an issue, project or patch utility instance) upgradable by the maintainer [0], and each submission is already signed. So if it becomes a big problem, we can write up a little expression that adds banning, rate-limiting, or removes certain content, from the materialized view, and anyone who wants to use it can.

That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.

[0] This is based on the eval-redefinition we describe here: https://ipfs.io/ipfs/QmadmGA6mBWZ93Wv4XKuCu9wdPf7Da8pjH3Corz...

View on HN

That sounds like it could be an issue if illegal content is accidentally accepted, the owner of the repository would have to continue to share it and users might be at risk of downloading it, even if they don't see it.

That plus moderation tools couldn't cut down on people trying to bloat the repository.

I think the same “problem” exists with GitHub, and the same solution exists here: the repo owner/ipns keyholder can rewrite history at will. Redacting information from the authoritative copy is possible.

Well with traditional git, you can use tools like BFG and remove files or rewrite history that might have accidentally contained a password or API key (sure you can change them, but it's also best to get rid of them in history). Since this is on top of IPFS, is that still possible, or are there cases where things will last forever?

Couldn’t you just solve this by requiring submissions to be signed with a key signed by another chosen trusted authority. This authority could either be the maintainer, or somewhere else which charges a nominal fee for a certificate.

> That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.

Which is still a disaster from a data privacy perspective (think GDPR requirements for deleting PII).

As u/sneak pointed out, you can also completely remove things from the logs. It goes outside the semantics of the Radicle language itself, so it's not exactly first-class, but is possible.

Reply on news.ycombinator.com