Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
๐ข Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
View quoted note โ
Login to reply
Replies (18)
How do you plan the route? Isn't it always user -> some relay -> other user?
Amazing new piece of #freedomtech just dropped. Hold on to your ๐ฅ
Ping @ODELL discuss this in the usual places please ๐ฑ
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
๐ข Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
View quoted note โ
View quoted note →
Npubs Tor Routing!?!
๐คฏ
NTR -> NosTR
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
๐ข Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
View quoted note โ
View quoted note →
Did I already say I love your awesome brain?
Do you think this could also support onion routed event reads?
no -- we're working on something different for anonymized event reads; this is only for publishing
Very cool. Curious if this could be used as a payjoin v2 async communication channel, but would need to be able to have the read side too
"Like Tor, just faster."
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
๐ข Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
View quoted note โ
View quoted note →
๐๐๐คฏ
Is this a fork of Eltor?
Who picks the mints in this case? Would relays have a list of accepted mints?
Could be done without ecash: https://devpost.com/software/el-tor


based
Pablo just being Pablo....
Yesterday we were playing around with ideas at @Sovereign Engineering , we needed something to preserve anonymity for blossom users that communicate with DVMs.
๐ข Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
View quoted note โ
View quoted note →
@PABLOF7z Sorry to dig up that old post -- is that implemented somewhere yet?
I'm not a programmer, just a user, so please don 't be annoyed. Is there a name (like TOR) for it to search for (on the web, in app settings and so on)?
it's implemented in nutsack-cli under the aptly named "condom" command
with nutsack-cli you can run a bunch of routers with condom and do routed publishing with the "publish" command
Thx for the fast response, finally I have a real incentive to go into this ecashu-thingy ๐ค
Is there a reason why I2P is not widespreadly used besides the lag in booting up? Mobile devices have an uptime like >99% anyway
Good job