pull down to refresh
0 sats \ 7 replies \ @k00b 11 Nov 2021 \ parent \ on: squeaknode - decentralized alternative to Twitter with lightning monetization bitcoin
Can you give a high level overview of how the network/protocol functions or drop a link to an explanation if it exists?
There are references to block hash in the protocol - is there a notion of blocks/consensus in squeak or is this referencing bitcoin blocks somehow? In either case, what motivated this design choice?
The docs are very sparse right now, I'm working on improving the docs.
The high level summary of the protocol is:
When you open a connection to another node:
- send "msg_subscribe" containing the list of addresses that you are following (plus block range that you are interested in)
When a node saves a new squeak:
- forward a "msg_inv" containing that squeak hash to all connected peers that have indicated that they are interested in following squeaks signed by that author.
When a node receives a "msg_inv" from another node:
- check if that hash already exists in the local database, and send a "msg_getdata" message back to the other node to get the data if needed.
When a node receives a "msg_getdata" (containing MSG_SQUEAK) from another node:
- send a "msg_squeak" containing the full squeak (encrypted, without the decryption) back to the other node.
When a node receives a "msg_squeak" from another node:
- save the received squeak in the database if it is valid (and in the following list). Send a "msg_getdata" request to get the decryption key for this squeak from all connected peers.
When a node receives a "msg_getdata" (containing MSG_SECRET_KEY) from another node:
- send a "msg_offer" containing a Lightning invoice that will provide the preimage to get the decryption key after being paid.
When a node receives a "msg_offer" from another node:
- save it in the local database (after validation). Now the user has the option to pay the invoice the invoice to get the decryption key and unlock the squeak.
reply
Oh yeah, I forgot to answer your question. It is referencing Bitcoin blocks.
reply
The purpose of referencing the Bitcoin block hash is to create a provable timestamp for the creation time of the squeak. It guarantees that the squeak was created at least after the time when the block was mined.
reply
And blocks are just a way of having a reliable means of providing time in a distributed context?
reply
Yes. Each squeak has a block hash embedded in it (before it gets signed). So when you download a squeak from another peer, you can verify that it was created after the block time.
reply
Also, is there such a thing as consensus in squeak or is it strictly a relay network?
reply
No consensus needed, just relay. It's a layer-3 protocol, so it piggybacks on top of Bitcoin and Lightning for all of the trustless stuff (timestamps, invoice payments)
reply