A model for cross-app comments with boostagrams #503
Replies: 3 comments
-
Where do the comments get stored and who is responsible for making them available to the apps? What is the protocol for sending and receiving the stored comments? I'm okay with some sort of comments file, sort of like a chapters file, and an api a podcaster has control of that uses an agreed upon protocol, and the app can send comments to that api, the api server aggregates the comments into a JSON file, and the JSON file is linked in the RSS feed, and the podcast app can fetch the JSON file and display the comments from it. I just don't want to develop the protocol. If someone else did, I would probably support it. |
Beta Was this translation helpful? Give feedback.
-
I'm having a hard time seeing what spec is proposed here. This sounds like a product feature request, but I'm not seeing how to tie it into an open standard we can encourage apps to adopt. Also, the spec for cross-app comments should not be exclusively tied to Bitcoin Lightning Network, because LN payments have totally unpredictable character limits, which limits its potential as a cross-app comment medium. Does LN work very well in certain contexts? Absolutely, but we shouldn't make a open standard like cross-app comments be bound to a particular implementation like Bitcoin Lightning Network.
This seems a little presumptuous. The cost is not just the 1 sat per message but 1) the cost to develop and maintain the feature, 2) provide customer support, 3) take on the risk of having an extra wallet loaded with sats that users withdraw from every time they comment (risk of hack / botting to manage), 4) the extreme volitility potential of Bitcoin price, and 5) my understanding is today it is common to be able to send 1 sat Bitcoin Lightning transactions, but that is with LN nodes who charge 0 sat fees...if adoption grows exponentially, network congestion will increase, which leads to higher fees on LN transactions as available node throughput decreases. App developers could find a budget they created for 1 sat per message suddenly has to cover 10 sats per message. (someone correct me if I'm wrong but I think that's possible) Anyway, there is a lot to be considered here. I don't necessarily see it as a bad product idea, it might be a very successful one, I just don't yet understand how it fits with open standards. |
Beta Was this translation helpful? Give feedback.
-
I hear you. I'm going to close and disregard this idea and take a new approach. |
Beta Was this translation helpful? Give feedback.
-
I do not like the idea of requiring people to pay to comment. But hear me out on this new idea!
What if we use boostagrams for cross-app comments, but each normal comment costs only 1§ and that fee is paid by the app, covered by a yearly cost the listeners pays to unlock premium features from the app.
With the cost of Bitcoin at around $30K right now, 1§ is worth 0.03¢. So if a listener makes 100 comments a month, that costs the podcast app only 3¢. Include commenting in a $10/year subscription to the app and the developer gets a huge profit margin, plus the financial support to innovate further.
These payments would default to come from the app's own wallet. But whenever someone comments, they have the option to boost their comment, which would require the listener uses their wallet, and then they pay the full lightning fee.
(I'll post a separate proposal to add a suggested boostagram minimum to the
value
block.)Or maybe it's something that the apps offer to podcasters, like "Pay $5 a year to unlock cross-app commenting for your podcast(s)."
I think moving cross-app comments to V4V payments would speed the adoption of cross-app comments and V4V micropayments because developers would have to support only one protocol, not both.
Beta Was this translation helpful? Give feedback.
All reactions