RSS3-Network
[Protocol Design] Who owns "comment"?
Assume there's a post P, owned by its author obviously. Then there's a controversial debate on who owns the comments to P? By commenters themselves or original poster. In case of ownership, we mean the permission to delete the content.
We can propose three types of ownership:
- owned by original poster (which also means delete cascade)
- owned by commenter
- co-owned by both original poster and commenter
Or even can we design that 4) the poster is able to determine the rule of its own ownership?
We almost have the agreement that 1 is not good for the healthy and free information flow. But whatever 1 makes sense on the point that the post owner can protect himself/herself facing cyberbullying in this way. Out of this reason, we propose an auxiliary mechanism: one can only comment with paying some social tokens issued by the poster or some party.
In case of the design and implementation details, it requires more discussions and considerations.
- As per our fundamental belief in the fact that data is born to be owned by the individual who produced it, we can easily eliminate 1 (Also it's under centralized control).
- 2 seems to be a straightforward implementation of our ideology, it challenges the completeness of the content graph without additional effort (like indexing and crawling).
- By quoting 1 in the implementation of 2, 3 is somehow achieved. OP can always delete/edit the original post.
- Well 4 seems to be a great and futuristic thing to think about. Maybe work with social tokens like Bitclout would be a better idea. Can be added later as an option, but doesn't sound like a thing we can do in the near future
I think every publisher could design the access controller of their contents, inside their posts or persona files. Firstly, we should not include a signature in RSS3 files, instead, we should put it along with the broadcast of operations (modification, addition, deletion) about a file. And then, we should specify an access controller inside our files, which could determine whether the signature is valid and the operation is legal. As node broadcast their operations toward a file, every node is able to check its validity. With such a mechanism, we could easily solve the problem of ownership at the cost of a handful of hair of our programmers (
Also, because the field '@context' is closely related to the field 'upstream', the operations of the RSS3List file in the context field could separate from the operations of the upstream field, which means that we could give everyone the right to;
- Post their comments freely to any other items (posts) and hide their comments from the original post (exist but invisible from the post).
- The owner of posts could choose to hide any comment but could not eliminate them from the network.
- The owner of posts could also specify the access of displaying comments of others by checking signature or proof of work (or maybe sending tokens).
The function of the signature is not only verification of operation between persona and node, but also verification of correctness between node and client, so including signature into the file is a better way
And I'm confused about the operations of the RSS3List file in the context field could separate from the operations of the upstream field, do you mean save @context and upstream in two different files?
My purpose is to make any operation easier to verify by separating signature with persona. We should consider that the signature is a part of the rss3 pointer. If clients need the signature to verify, the server could read the sign from the pointer and just return it. Although this may post a new problem considering the verification of a single item. I believe this problem could still be solved by either presenting the Merkle Tree of the persona or splitting items into single files. If you think this solution is quite complicated, the signature could still be included in the file.
In my understanding, @context and @backlink are both List files and they could be generated by looking at the upstream field in other items and links in other personas. However, if nodes generate these files themselves, they would need to store all the items created by all personas. This is unrealistic in a decentralized system. We should allow the author of a comment to modify the corresponding @context to include their own comments in another person's item.
But we need to verify the integrity of the file, for example, to ensure that a node has not intentionally dropped an item or a field, and to do this persona need to sign the whole file, not just a particular operation
The decentralized implementation is still under consideration, but instead of storing all items created by all personas, the node only needs to synchronize its missing records with other nodes
We should allow the author of a comment to modify the corresponding @context to include their own comments in another person's item is an interesting idea, I'll give it some more thought
I don't seem to make it clear. This signature is generated from the file instead of just this operation. We could separate the signature from the file to reduce the coupling.
storing all items created by all personas is just a condition that appeared only if we let every node generate the RSS3List in @context and @backlink themselves. It's not the same thing with the design of decentralized implementation. If you think that the idea We should allow the author of a comment to modify the corresponding @context to include their own comments in another person's item could work, this problem can be solved.
I see, it's the same problem as #4 so I'll just reply here, maybe the point is whether we should design a mechanism for multiple personas to manage the same file, if so, it might be beneficial to separate the signatures
From my point of view, it is necessary to design a flexible protocol so it is more user-friendly. Specifying the access controller in each file would allow wider range of operations to take place, e.g. multi-signature. However, some details could still be in debates such as how to write the access controller. I'm not sure so this may be considered later.
If I understand this correctly, this is suggesting that we treat RSS3Files as trackers for content publishing while separating ownership and access control information in a separated persona file?
My purpose is to make any operation easier to verify by separating signature with persona. We should consider that the signature is a part of the rss3 pointer. If clients need the signature to verify, the server could read the sign from the pointer and just return it. Although this may post a new problem considering the verification of a single item. I believe this problem could still be solved by either presenting the Merkle Tree of the persona or splitting items into single files. If you think this solution is quite complicated, the signature could still be included in the file.
In my understanding,
@contextand@backlinkare both List files and they could be generated by looking at theupstreamfield in other items andlinksin other personas. However, if nodes generate these files themselves, they would need to store all the items created by all personas. This is unrealistic in a decentralized system. We should allow the author of a comment to modify the corresponding@contextto include their own comments in another person's item.
Access control can be included in the RSS3File in the form of a field, so it does not need a separate file. Every node could use the access control information in the RSS3 file and signature in the broadcast to validate a certain operation.
If I understand this correctly, this is suggesting that we treat RSS3Files as trackers for content publishing while separating ownership and access control information in a separated persona file?
And I'm also considering using some non-Turing complete languages as the access controller part. This could enable some basic operations such as not allowing the publishing of an article with a specific title.
Access control can be included in the RSS3File in the form of a field, so it does not need a separate file. Every node could use the access control information in the RSS3 file and signature in the broadcast to validate a certain operation.
If I understand this correctly, this is suggesting that we treat RSS3Files as trackers for content publishing while separating ownership and access control information in a separated persona file?
This actually makes a lot of sense and I really like this. We should seriously working on the possibility of reconstructing access controls for the next version of RSS3 Standard. Well done!
And I'm also considering using some non-Turing complete languages as the access controller part. This could enable some basic operations such as not allowing the publishing of an article with a specific title.
"not allowing the publishing of an article with a specific title" seems a bit confusing to me. Is it about the user not allowing himself to publish a certain thing? Or is it a control for a joint access RSS3 file?
I just made an unsuitable example. This means we could control the access with respect to aspects other than signatures. We could check the validity of a post by looking at whether its title, time or other things matches the requirement set in the access controller.
"not allowing the publishing of an article with a specific title" seems a bit confusing to me. Is it about the user not allowing himself to publish a certain thing? Or is it a control for a joint access RSS3 file?
I just made an unsuitable example. This means we could control the access with respect to aspects other than signatures. We could check the validity of a post by looking at whether its title, time or other things matches the requirement set in the access controller.
"not allowing the publishing of an article with a specific title" seems a bit confusing to me. Is it about the user not allowing himself to publish a certain thing? Or is it a control for a joint access RSS3 file?
Oh yeah that makes sense. This can be an interesting part of the RSS3 file which can definitely enable some more sophisticated usages. I can't think of anything specific at this moment but there has to be some
This could definitely contribute to the flexibility of the RSS3 protocol. However, it is also difficult to implement. To start with, we should first design a protocol that allows multi-signature and different types of personas (e.g. organization) and gradually turn into more complex solutions.
This could definitely contribute to the flexibility of the RSS3 protocol. However, it is also difficult to implement. To start with, we should first design a protocol that allows multi-signature and different types of personas (e.g. organization) and gradually turn into more complex solutions.
Yeah that sounds really interesting, we should loop deeper into that next quarter when updating the RSS3 Standard. Hope you're participate in the update as well through RSS3 DAO
We now use the controller to define who controls the file, the content of the controller is a contract address, and the implementation of the contract needs further discussion.