By design, LN's messaging is only client side anonymity. Normal payment protocols in LN require the payer and payee know each other. Keysend and AMP can enable spontaneous payments without telling the receiver who is sending, and also this can bundle messages.
But I don't think it can really perform this duty as well as payments, and client side anonymity is a limited use case. To do full bidirectional anonymity (hidden services) the protocol is also going to need an anti-spam anti-sybil consensus.
Thanks for clearing that up, I was wondering about the implimentation but I couldn't find a much discussion on it or why it never become a use case I mean it would make sense to me to be able to communicate through channels to coordinate with one another with your channels
I never really saw it as a replacement for chatting which like you say would bring on its on attack vectors
Yes, roasbeef, if you dig through his posts on issues and whatnot has talked about the idea of adding this functionality but it only takes a little bit of thought to see why this has not been fleshed out in any significant way yet.
It's one of the key features we intend to build on top of Indranet in the near future, with the same basic design as used by the abandoned Torchat app, which used hidden services to create p2p connections between users and used hidden service keys as their identifiers.
I only just came up with a design that uses the same style of source routed onion messages as used in LN for payments that enables bidirectional anonymity. The purpose in LN is not anonymity between parties involved, but to exclude those on the paths from knowing the identities of both sides of the exchange.
The trick to it has to do with an idea I invented called "routing headers" and makes use of a pair of secret keys known only between the client and the relay, the routing header is encrypted to one of the two keys, and the relay is provided the direct ciphers and nonces to use in encrypting the reply messages. This first of all enabled a loop path, so that clients send messages and the endpoint can forward their message to a service and then when they get a reply they attach it to the header after encrypting it with the provided keys.
Then, by making it so the endpoints between a hidden service path are sending these routing headers back and forth in a bidirectional manner, preventing unmasking by having the header prefixed by a header for the forward path, and providing a subsequent return routing header, both sides don't know where each other is, and cannot unmask each other's network location.
By design, LN's messaging is only client side anonymity. Normal payment protocols in LN require the payer and payee know each other. Keysend and AMP can enable spontaneous payments without telling the receiver who is sending, and also this can bundle messages.
But I don't think it can really perform this duty as well as payments, and client side anonymity is a limited use case. To do full bidirectional anonymity (hidden services) the protocol is also going to need an anti-spam anti-sybil consensus.
Thanks for clearing that up, I was wondering about the implimentation but I couldn't find a much discussion on it or why it never become a use case I mean it would make sense to me to be able to communicate through channels to coordinate with one another with your channels
I never really saw it as a replacement for chatting which like you say would bring on its on attack vectors
Yes, roasbeef, if you dig through his posts on issues and whatnot has talked about the idea of adding this functionality but it only takes a little bit of thought to see why this has not been fleshed out in any significant way yet.
It's one of the key features we intend to build on top of Indranet in the near future, with the same basic design as used by the abandoned Torchat app, which used hidden services to create p2p connections between users and used hidden service keys as their identifiers.
I only just came up with a design that uses the same style of source routed onion messages as used in LN for payments that enables bidirectional anonymity. The purpose in LN is not anonymity between parties involved, but to exclude those on the paths from knowing the identities of both sides of the exchange.
The trick to it has to do with an idea I invented called "routing headers" and makes use of a pair of secret keys known only between the client and the relay, the routing header is encrypted to one of the two keys, and the relay is provided the direct ciphers and nonces to use in encrypting the reply messages. This first of all enabled a loop path, so that clients send messages and the endpoint can forward their message to a service and then when they get a reply they attach it to the header after encrypting it with the provided keys.
Then, by making it so the endpoints between a hidden service path are sending these routing headers back and forth in a bidirectional manner, preventing unmasking by having the header prefixed by a header for the forward path, and providing a subsequent return routing header, both sides don't know where each other is, and cannot unmask each other's network location.