for those who have heard me talk about indra, this is the juicy, most human-readable form of the design that you can find:

https://github.com/mleku/indra/blob/master/docs/formats.md

before i go on, a tl;dr: indra is a connectionless, prepaid micro-session based source routing protocol that is intended to be used for providing traffic analysis security, similar to Tor, but due to its use of lightning micropayments and sessions, also enables the creation of network-native paywalling systems.

it would enable spam control for nostr, for one thing, and it would eliminate location correlation for bitcoin, and it would enable opaque paths for channels that would prevent state-sized actors from discovering the flow of lightning payments from one user to another, in the same way as currently Tor is used, in addition to lightning's native TLV source onion routing. (indra borrows this as its primary method of constructing paths, but turns it into a network transport, not just short messages but intended for bulk traffic and low latency realtime interactive traffic).

the implementation lags a little behind the specification above. two key elements have not made it to the codebase yet:

- the change of the header size specification with the "offset" (the initial implementation made the onion headers fixed size)

- the use of a connectionless, UDP based network protocol, which is essential due to the problem of scaling the network beyond a few hundred nodes with the current code's use of the libp2p connection oriented protocol.

the offset issue is part way implemented.

the connectionless messaging and DHT protocol still needs to be fully designed. it's a bit of a challenging problem to work out because UDP messaging protocols require the implementation of a flow control system, and with the naturally random nature of indra's messaging, it will require some special considerations to cope with delivering low latency while routing blind and avoiding heavy congestion.

if you are a go programmer, you might be curious to browse through the code, i can tell you the first port of call should be the engine, which is the event loop that manages sending and receiving messages, forwarding them both internally and to external relays to forward onwards.

i would dearly love to be able to go back to working on this project full time, but right now i need money and for that i'm working on simpler things that have a more certain future cash flow.

looking back over the codebase so much of it is mindboggling what i wrote, it's not that it's hard to read, but that to understand it you have to be able to trace the flow of data through the thing, and understand the abstraction and architecture before it is clear what it does.

anyhow, i obviously need to focus on what is gonna pay for my next backpack full of milk but i need to put this out there and remind people i spend a year working on this, october 2022-october 2023 and much of the code is written, but implementing the two elements mentioned above must be done first before it can be put on a network.

nostr:nprofile1qqsxu35yyt0mwjjh8pcz4zprhxegz69t4wr9t74vk6zne58wzh0waycpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7qg3waehxw309ahx7um5wgh8w6twv5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0rxq4v7 i know i mentioned it to you previously, nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgpzemhxue69uhkummnw3ezumtfd3hh2tnvdakz7qghwaehxw309ae8xumvv9ujumn0wd68ytnwv46z7qgmwaehxw309aex2mrp0yhxummnw3exjcmgv4ejummjvuhsr0gzs6 this is what i've maybe mentioned somewhere in the past. a lot of the basic work has been done, i'd love to get some ideas about how to go about getting this thing going. nostr:nprofile1qqs9njktmqadt322myw6eag6f8qxuzl0wv9vpe7zxkn0d73fhy3s7qspr4mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mf0qyvhwumn8ghj7mrfva58gmnfdenhyetvv9ujucm0d5hsz8mhwden5te0dehhxarj94ex2mrp0yhxgetjv44hymmnwvhx6ef0gsgz6z the payment streaming system you talked about might be relevant to this project, perhaps it can be meshed together with it or perhaps there is reason to think that the idea of micro-prepaid-sessions is a viable model for simple connectivity, as opposed to specific content delivery.