Addtional content when linking notes

[Fooooooooooox]

Right now, linkNote can be served to link notes for different purposes by assigning different linkTypes, but it's quite limited, cuz the linkType is bytes32 and can only be used to store a small amount of information. Imagine a scenario when you liked a bunch of posts on Xlog but you want to tag them with different bookmarks and organize them into different lists, the linkTypes alone won't be enough.
We got 2 options to improve this:

1. add a linkNoteWithUri method in Web3Entry.sol.

  /**
   * @notice  linkNoteWithUri creates a link between a character and a note, and at the same 
              time attaches a uri to the link.
   * @param   vars The linkNoteData struct containing the following parameters:
   *      * fromCharacterId: The character id of the linker.
   *      * toCharacterId: The character id of the note owner.
   *      * toNoteId: The note id of the note to link.
   *      * linkType: The link type to use, for example, `LikeLinkType`.
   *      * data: The data input for link module, if any.
   * @param   uri The uri attached to the link, which can contain anything depending on how 
              you want to use it.
   */
function linkNoteWithUri(struct DataTypes.linkNoteData vars, string uri) external {}

This uri can be anything, we can put the tags we want in it.

2. leave the existing interfaces unchanged, but upgrade Web3Entry.sol to distinguish between the Events of link and `linkTag'.
   When you want to link notes with tags, your linkNoteData might be like this:

{
  "fromCharacterId": ,
  "toCharacterId": ,
  "toNoteId": ,
  "linkType": "tag: bc's reading list",
  "data":
}

In order to make some differences with the emitted events so that indexer can easily tell if this is a normal link or a linkTag, Web3Entry would process the input data and when the linkType starts with "tag: " the linklistId in the emitted LinkNote event would be 0(normally the linklistId should be linker's linklist ID).

What do you think, Which one is better? 🤖

[Atlasoin]

Imagine a scenario when you liked a bunch of posts on Xlog but you want to tag them with different bookmarks and organize them into different lists, the linkTypes alone won't be enough.

Agree with this scenario. "Tag" and "List" are both useful for different purposes. Currently the linkType is more suitable for "list".

For 1, that's intuitive, and I like the flexibility using "uri" instead of pure string arrays, which means you can attach not only tags but also, for instance, quick marks, to a note you want to bookmark. But from the protocol's perspective, I am afraid it is not general enough.

Comparing with creating a list, tagging are more to deliver some information. From this point, I believe, "tagging" content is supposed to be commented/liked as well. Both solution 1 and 2 are not good at that.

So I wanna propose 3: using postNote4Note to tag a note, which means, tagging a note is essentially to post a new note. (I know postNote4Note has been used for comment case. But honestly, tagging and commenting has lots in common.) Then to bookmark and tag a note are essentially two txs:

• bookmark: link a note with a linkType "my reading list"
• tag: use postNote4Note to post a new note with content:

{
  "tags4note": ["literature", "freedom"],
  "action": "curate"
}

Here I introduce a new trait name aciton, which is to distinguish the normal "comment" case which also uses postNote4Note. A normal "comment" note might look like:

{
  "content": "Agree with you.",
  "action": "reply"
}

That distinguish is useful to determine which notes are included to display as comments under a note and which are not.

If we want to update the tags, we can post a new note to replace the old one, or use setNoteUri to update this note.

Pros are it's more clear and no interface change. Cons are that the indexer has to do a lot of things:

• maintain the tags of each note
• distinguish if this is a comment or curation
• index the notes by tags when user requires
• etc

Besides, though flexible enough I know that design might be too abstract and not easy to understand.

Hope to know more thoughts from you!

[songkeys]

My suggestion is that we do not change anything on contract. We could give the linkType a convention:

linkType: [^:]+(:[^:]+)* (i hope i get it right)

That is, separate the sub-types with :. Some examples:

• favorite collections:
  • fav
  • fav:collection-1
  • fav:collection-2:the-best (multi-level)
• like something but with emojis:
  • like:heart
  • like:thumbs up
  • like:right-facing fist

(The colon just happens to come out of my head. It could be some other special character.)

When querying on indexer to find the total list, we only have to change the equals queries to startsWith ones. No more changes are made. Totally compatible. Only thing we add is just a convention which only deserves noticing when the developers ask for this use case.

[iavl]

My suggestion is that we do not change anything on contract. We could give the linkType a convention:

linkType: [^:]+(:[^:]+)* (i hope i get it right)

That is, separate the sub-types with :. Some examples:

• favorite collections:

  • fav
  • fav:collection-1
  • fav:collection-2:the-best (multi-level)

• like something but with emojis:

  • like:heart
  • like:thumbs up
  • like:right-facing fist

(The colon just happens to come out of my head. It could be some other special character.)

When querying on indexer to find the total list, we only have to change the equals queries to startsWith ones. No more changes are made. Totally compatible. Only thing we add is just a convention which only deserves noticing when the developers ask for this use case.

I agree with this. It is worth noting that linkType is bytes32 type, so its length is at most 32 bytes.

[songkeys]

@Albert Different encodings can result in different storages. How many characters can 32 bytes hold in solidity?

[iavl]

@Albert Different encodings can result in different storages. How many characters can 32 bytes hold in solidity?

maximum number of uint256, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

[Atlasoin]

Use linkType with conventions result in some confusions in contract level:
like:heart and like:thumbs up will put two notes in two different nfts(in protocol, a list is an asset(nft)) , but essentially they are supposed to be in the same nft: "my likes nft".

[iavl]

maybe we can reserve a flag bit(taking the last bit of linkType for example) to indicate whether to create a linklist nft when linking, maybe like this

bool flag = linkType & 0x1