Refactoring bolt.fun nostr-powered commenting feature - Part 2
A commenting system built on top of Nostr consists of 2 parts:
1- The thing being commented on
2- The comments themselves (obviously)
For the 1st one, in our case, it's a story.
If comments were to appear by themselves on different nostr clients, they would look just like random pieces of text.
So to make them have more sense, we need to put a reference to the story they were commented on.
But (currently), we are not posting our stories to nostr, so we need to find another way.
This way will be:
Publishing a "root" event that contains will act as a representation for the story on the nostr network.
It won't contain the story content, only its title, and probably the URL.
Now each comment posted on this story will reference this "root event" by including its id in its "#e" tags.
At this point, we came across several hard questions regarding the creation of this root event.
Here are some of them, and how we decided to go about them.
(If you have some suggestion or opinion, please tell us).
Q: Whose keys should be used to publish this root event?
The user's keys or a bolt.fun keys??
A: Bolt.fun's keys.
This would allow users on external platforms to query for all the posts that are published by our users just by using our pubKey.
(Of course we could include the original author's pubKey in a field in the story object)
----------------------------
Q: At which stage should we publish this root event??
A: Right after the user publishes his story & our api returns a success response.
---------------------------
Q: Should we make the user aware about publishing this event, or should we do it in the background??
A: There is several pros & cons for both approaches.
The event will be signed on our backend, but it will be either published from the client or on the server.
In the case of the client: Some prompt (modal) would be shown to the user asking him whether he wants to publish his story to Nostr or not & enable commenting on it.
Upon confirmation, the event will be published there.
_⬆️ Pros:
_- Users are more aware about Nostr integration
- This means that users are more likely to learn more about nostr & understand about its pros & cons
- Giving the users control over whether they want to publish their story on nostr & enable comments or not (maybe they don't wish to...)
_⬇️ Cons:
_- Users who don't know anything about Nostr might be somewhat confused & not sure what to choose.
- Will add an extra step to the "Create-Story" journey. (Might be eased a little by adding a checkbox that says something like: "Always agree to publish" or something)
In the case of the server: The user won't see anything.
The server will invoke a background function that will call handle publishing the event.
⬆️ Pros:
- "Create-story" journey stays as is, without any new extra step
- Less new info for users who don't know what Nostr Is.
⬇️ Cons:
- We might be losing a good opportunity to encourage users to learn more about nostr
- Because the publishing will happen in the background on the back-end, it might fail silently (we can show a publishing status or something to handle this)
- Will add some complexity on the back-end
We are still not completely decided on which approach we should follow here...
But currently, we are leaning more toward the "Do it in the background" option.
Primarily because it's less hussle for the user.
But we are very open for any suggestions or other point of views. So feel free to shoot'em 🚀
Stay tuned for the next part.
But until then,
have a nice day 👋