Just uh, run me back the part about your project so I can give it a boost, very low awareness of your project right now and I dont see a good post to send out. Having stayed behind VPNs for years now I honestly cant wait for your project, its probably the thing I am the most excited for and im so happy to have found you here. It is valuable enough to me to mirror my VPN subscription to you, just give me a good summary so we can try to get more people to notice.
Quantum computing is fiat nonsense. Do you know how much power it requires to cool the q-bits? Even if it accelerates a password crack by a million times it's still 1 year with the equivalent of a 100k pop city of energy consumption, and that entirely assumes that Schnorr's algorithm is actually going to work, which isn't a given either.
It's the same fantastical nonsense as vat grown meat and vegan collagen.
https://git.indra-labs.org/dev/ind is my work. My work is based on making use of LN to act as a monetary incentive and spam prevention mechanism for a relay routing system, like Tor, but based on the same type of cryptography used in Lightning.
And I'm a terrible marketer, I haven't got a snowflake's chance in hell of having my work funded at this point.
Discussion
It's a relay network where you make lightning micropayments for small prepaid balances creating sessions with many relays, then your client uses these sessions to create multi-hop paths to reach services, which are advertised exit protocols that relays advertise.
If your message is just a broadcast, such as a bitcoin transaction, you can watch to confirm it got to the Bitcoin p2p network via other channels, but to enable privacy for clients, while the server is public, you send special types of messages that carry requests to these services, which I call "reply headers" and they contain a secret path to return, and the ciphers to encode the message on its way back to you.
The payload is already known to the exit anyway, and it knows how many hops the path back will be, but it does not know the keys that combine to create the set of symmetric encryption keys, or who will be receiving them and unwrapping their layer of the message beyond the first hop, and because the path is selected by the client, it is unlikely that an evil exit will also be in cahoots with more than one of the intermediary hops.
This creates "client side anonymity", which is to say, the exit is public, but the client is hidden. The relay operator can indeed be running the service themselves, on the same machine, or elsewhere, through the use of a firewall forward or similar.
Then, hidden services can advertise their existence via these client side private routes, and deliver a reply packet and intro to their chosen introducer, clients can request an introduction after receiving the ad for the introduction on the p2p gossip network, and deliver a request containing the client reply headers, to the introducer, and then back to the hidden service, who then can send a new reply header to the client using the client's routing header, and so on and so forth, as the server and the client can now negotiate their reply paths to each other independently of the introducer.
The hidden service will accept reuse of some prior reply headers in case of a transmission failure, when one of the hops in the reply header fails for some reason, but worst case the client uses another introducer to get a new connection established.
This is "bidirectional anonymity" or hidden services.
The last piece of it, is that it requires a connectionless p2p network transport, in order to minimise latency. I already have a protocol that uses libp2p and tcp, but this protocol adds tcp handshake delays every time a client constructs a path that the hops along the way are not "connected" to - whereas with a connectionless transport, it just delivers it and the next point in the path expects random messages from everywhere, and it doesn't maintain any state aside from the sessions that clients paid for.
This all will enable not just privacy, both client, and client AND server anonymity, it also allows relays to put a price on delivering messages to other network locations, such as their own stash of content, which can potentially be monetised to distribute the content, using Prisms or potentially even special redistribution licence fees, or other possible schemes that use cryptography to guarantee the payments are divvied up, and it would enable things like wifi internet access, while getting paid for it, and without becoming a man in the middle for malicious actors who won't profit if they have to pay for the traffic (eg spammers).
In other words, it could help the spam problem on nostr as well, protect bitcoin users from doxxing their location and where the private keys are located, and likewise for LN operators, whose location is a vulnerability for attacks for the same reason.
It's difficult to explain it any shorter than that, and I'm very very welcoming of anyone who can boil that down so it's understandable. I know that LN was completely opaque to me at first, and even after reading the WP, and many further articles, I only started to grasp it a bit.
Feel free to feed it to an AI, make a short version, join in and help bring funding to it.
It should be obvious that I'm not the person to write such marketing, I'm the one engineering it!
I didn't mention the "lightning bolt" decoy propagation patterns or the delay messages or several other things. This is just the VPN use case and a little hint at the paywall use case.