pull down to refresh

[RFC] Shroom Node v0.1 released
3 sats \ 4 comments \ @carlos99 7 Oct 2021 bitcoin

TLDR: [(Impervious.ai + Sphinx Chat) x (open source + MIT license)] ^ REST API = Shroom Node

Shroom Node runs on top of LND, and it has one job: to relay generic data to and from other Shroom nodes.

The goal is to have this as an open-source framework on which other apps and services can be built. It would abstract away the details for exchanging data and payments peer-to-peer.

Just released v0.1 which includes a sample chat app.

Feedback and comments appreciated.

write
preview
related posts
1 sat \ 3 replies \ @k00b 7 Oct 2021

Awesome! Great to see an open source project doing lightning transport.

I haven't messed around much with lightning transport yet. What do you see as the benefits of using lightning as transport vs other things? What are the limitations of lightning as transport as it stands?

I'm particularly curious because I want to decentralize SN and the hard part is providing p2p Sybil resistance absent centralization - I have a high level design I think will work but I'm considering alternatives. One way would be to use lightning as transport which has a natural cost to message sending, but for programmatically generated p2p messages I suspect it'd be prohibitively expensive.

reply
102 sats \ 0 replies \ @carlos99 OP 7 Oct 2021

Thanks k00b, good questions.

LN as transport is something I'm exploring. I want to use it as much as possible, but I think for some use cases I might have to use it only for signalling and transfer actual data over something else, like a websocket.

On the one hand, it has some interesting benefits, like:

  • you only need a pubkey to contact someone (they could change IPs, switch over to tor and back, etc -- still reachable via same pubkey)
  • "data bound to payment" = cost of sending = native spam prevention
  • "data bound to payment" = receiving data implies receiving a payment = economic incentive to offer services (for which the inbound messages can be "requests for service")

On the other hand, limitations:

  • latency: you can't quite "stream data" over LN (maybe not yet? or maybe its not necessary, a side-channel can be used for low-latency requirements?)
  • bandwidth: same as above
  • payloads are persisted (indefinitely?) as invoice metadata in the LND DB = could eventually clog the DB
  • makes one-to-many scenarios harder to implement (a chat group where each message = N payments, one to every other group participant, makes no sense)
  • same for many-to-many

Will probably end up using it as a hybrid (transport in some cases, signalling in others).

Don't think this can help much with decentralizing SN though.

reply
1 sat \ 1 reply \ @carlos99 OP 8 Oct 2021

Hey k00b, I hear BOLT12 plans to support messages without payments.

Onion Messages Using the same onion mechanism we use to send payments, without the actual payment part. You can (and people do!) use fake payments to send messages today, but it's 3x slower and consumes far more resources on each hop. https://bolt12.org

Might be useful for decentralizing SN.

reply
0 sats \ 0 replies \ @k00b 8 Oct 2021

I didn’t realize that. Sounds like AMP/keysend I guess. Still, I’m not sure Lightning transport is the way but it’s interesting to consider.

reply