What would a native Intuition commenting system look like?
As the Intuition ecosystem becomes more mature, it is clear that current conventions work well at describing what a person is claiming but can struggle to concisely explain why a claim has been made. Recent implementations of file attachment claims have proven to be a major step forward, but they don’t fully address lightweight explanation and discussion.
Considering Intuition’s ability to relate items, concepts, and thoughts to one another, It seems natural that a native commenting primitive could emerge. Comments could be attached to almost any graph object—atoms, triples, web assets, concepts, lists, communities, or even other comments—and displayed by any frontend. In fact, we can borrow many existing web2 patterns with customizations to accommodate Intuition enhancements and general web3 considerations.
Representing Comments
Modeled as an object, a comment typically comes with a few core characteristics:
- body or text* - the main content of the comment
- author* - the account that created and posted the comment
- timestamp* - date and time when the comment was posted, to help establish the sequence of a discussion
- @type* -
Comment? Schema.org - parent - the item that the comment refers to (eg an article, identity, atom, or other comment)
The author and timestamp can largely be inferred from blockchain transactions. Rather than storing the parent inside the comment itself, it may be cleaner to express that relationship as a triple like [comment] - is reply to - [parent item]. Considering the data size limitations of the JSON-LD (inline), the IPFS JSON atom type is a good fit that would also allow arbitrarily extending the comment properties beyond what is required.
Comment Nesting
A comment may require a parent item to provide context for what is being commented upon. Using Intuition is reply to (or something like that) predicates would make it very easy to find comments related to the parent item (atom). There need not be a limit to how many levels deep a conversation can go, although individual dapps set their own nesting limits
Spam
Considering the reliance on IPFS to host the comments, as well as the space it will take up on an Intuition indexer, frontends may choose to require that low-quality comments do not clutter up the system. This can take the form of dapp-enforced fees, or triple / atom stake where dapps enforce minimum stake to even host or index the content. Token burning is also an option.
Also, considering that IPFS files require perpetual hosting that often requires per-month billing the network will have to find the best way to ensure that the comment JSON files receive ongoing, and redundant, hosting.
Editing and Deleting
A proper commenting system allows users to edit their comments, but this runs counter to how blockchains function. While historical revisions remain on-chain, frontends can decide how prominently they expose them and whether to honor requests to hide deleted comments. Also, the more the systems gets used the more difficult it will be to dig up old comments (revisions) that a user wanted deleted. With some exceptions, dapps could ignore or fulfill an author’s wish to delete their comment… delete is just a request by the user, not a guarantee. Graph data could even be considered in the process (eg disallow editing or deleting comments that have replies or other triples attached).
Editing could simply be encoded with a triple like [comment revision] - supersedes - [original comment]. Replies can still point to the original content, with dapps just preserving the link between revisions. Earlier editions of the comment could remain on-chain and viewable to the public dependent on the specific dapp’s policies.
Abuse
A major challenge faced by all online commenting systems is abusive content. Whether profanity, linking to external abusive material, or even unauthorized advertisement the commenting system would need protections. The community can use Intuition triples to report abusive comments or authors using triples (eg [comment] - reported for - [NSFW content]) which could even allow different dapps to moderate their comments differently based on what kind of abusive content is in the comment. Dapps can also look at individual commenters and use proprietary algorithms to restrict comments from low-reputation accounts.
Conclusion
Ultimately there are many ways that comments could be implemented on Intuition. By reaching agreement on conventions not just could we extend our network’s functionality, but we could also be building one of the first successful cross-platform commenting systems. A lot of questions still remain but I’d figure I would get the conversation started.