See trollbox.md for rationale. Would be a good way for token creators to communicate with their users and vice versa.
Details
- Reviewers
tobias_ruck - Group Reviewers
Restricted Project - Commits
- rABC7a59b64e4ccc: [new lokad] Add spec for onchain trollbox for tokens
proofread
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
doc/standards/trollbox.md | ||
---|---|---|
21 ↗ | (On Diff #50560) | Any reason not to use eMPP? Also I'd some add the following:
So simply change this to be:
|
doc/standards/trollbox.md | ||
---|---|---|
21 ↗ | (On Diff #50560) | no reason, just didn't occur to me EMPP is probably better. More extensible, fewer bytes. |
We might also want to use Shammah's CashWeb, which is much more generic and powerful, but also creates much less data on-chain:
Code: https://github.com/givelotus/cashweb
Whitepaper: https://www.stampchat.io/whitepaper.pdf
OTOH, starting with a super simple version of this first and then switching to something more elaborate later IMO could make more sense.
doc/standards/trollbox.md | ||
---|---|---|
21–26 ↗ | (On Diff #50564) | |
36 ↗ | (On Diff #50564) | You might wanna spec a message type for these rules already, depending on how you want to identify token creators. Trollbox devs can then query the display rules from the chain. |
improve spec description in line with suggested comments, provide spec for Cashtab planned implementation
doc/standards/trollbox.md | ||
---|---|---|
14 ↗ | (On Diff #50573) | This is volatile data, you can't rely on this |
doc/standards/trollbox.md | ||
---|---|---|
14 ↗ | (On Diff #50573) | Can't rely on it for important stuff, no. But, similar to tx history in herald or cashtab -- imo it's good to sort by timeFirstSeen when available (lets you do things like show unconfirmed txs "in order"). Usual approach is to if tx is unconfirmed:
if tx is confirmed
For the purposes of a trollbox I think it's good enough. |
doc/standards/trollbox.md | ||
---|---|---|
14 ↗ | (On Diff #50573) | my thinking is that the trollbox component will have a websocket subscription to a plugin that indexes these msgs by tokenid there's a good chance that "old" msgs could lose timeFirstSeen, since who knows what chronik node is connected; these could have strange sorting. but messages coming into the websocket are very likely to have timeFirstSeen, meaning live chat will be well sorted. |
Otherwise seems good to go, the timeFirstSeen seems fine.
doc/standards/trollbox.md | ||
---|---|---|
26 ↗ | (On Diff #50573) | Oh brainfart btw we have to pick one endianness here, otherwise we can’t find the token. I recommend little-endian, to be in line with ALP and the rest of Bitcoin. Big-endian would be what SLP does. |
doc/standards/trollbox.md | ||
---|---|---|
26 ↗ | (On Diff #50573) | does that mean we can only index trollbox txs for ALP, and SLP needs some other spec? |
doc/standards/trollbox.md | ||
---|---|---|
26 ↗ | (On Diff #50573) | No, it can be for both, we just have to pick one of the two encodings and stick with it |