@libs is on PowPing!

PowPing is a place where you can earn Bitcoin simply by socializing, for FREE.
Never tried Bitcoin? It's OK! Just come, socialize, and earn Bitcoin.
Check out libs's activities
Total Economy: 0.05 USD
This is nice. Thank you. Here's something to mull over. If a post can have many versions, with each version being a separate tx with unique txid, how is the best way to represent that in a bitfeed?
The "Bible" of investing is "Security Analysis" by Graham & Dodd, but it has MANY versions. Some prefer the original 1930s version. Some prefer the newest version updated for modern stocks and companies and times. But it's nice to be able to see the iterations, with their respective time-stamps in one place, to make that decision. Same goes for articles. For my articles, I want to do revisions, but don't want to lose control of the original. It allows both myself AND the reader to see where I've made mistakes and corrections. This is equivalent to Google Docs' version histories (available only to the author), but this would be for both author AND reader. That way, confusion doesn't occur "you said this... no I didn't... you changed it... no I didn't.....etc...." All this was quite important in the CSW Kleiman case, as a perfect example. Another perfect example is CSW has never "updated" the original White Paper, to keep it in historic context. But he should, it should just be done in versions which are open and stacked. Either that, or I have no idea what Bitfeed is, which is entirely possible.
I think we should adopt a layered approach like TCP/IP. Bitfeed was designed to be as minimal as possible and unopinionated just like IP is. It only cares about publishing transaction IDs just like IP doesn't care about reliability. That way we can overlay multiple different layers on top.
libs replied:
Sounds like what I need is a "metafeed" ... in my case the canonical reference is a bitcoin address. But can still serve up the rawtx of the latest version.
unwriter replied:
Couldn't you just include all transactions in bitfeed, and let the edge handle the interpretation? After all, the transactions should be self-contained.
libs replied:
Thats one option. But that feels like not a very useful feed if the receiving end has to sort and dedupe it. I think theres a few options: 1. Take a liberal interpretation of "id" and put my ids in the feed which are not txids. But ARE canonical and globally unique. 2. Include every version of every item in the feed and let the receiving end worry about parsing and deduping. 3. I just include the latest txid of each item in the feed so there is no deduplication, but then the receiving end will struggle keeping track of whats been read etc. To be honest, the pragmatist in me favours option 1.
unwriter replied:
> But that feels like not a very useful feed if the receiving end has to sort and dedupe it. The same could be said about IP, because IP alone can't do much. It's not a bad thing. See end-to-end principle https://devopedia.org/end-to-end-principle In that sense, option 1 would not be Bitfeed, it would be a different specification, which is fine. But what i meant by layering was whatever gets layered on top needs to respect the lower level definition. In that sense, option 2 and option 3 both can work on top of Bitfeed.
libs tipped:
0.05 USD
1 month ago
libs replied:
Thanks for the reading :) ok I'll think on this