Profile: 5b459807...
Because it is even worse than that, or at least that's how I understand it. The Whirlpool client uses a session ID for all requests and the server attachs that session ID to all websockets in order to identify them. The server even logs all that info.
```
> grep log **/*.java | grep username
main/java/com/samourai/whirlpool/server/controllers/websocket/SubscribePoolController.java: log.trace("(<) [" + username + "] " + headers.getDestination());
main/java/com/samourai/whirlpool/server/services/WebSocketService.java: log.warn("(>) " + username + " sendPrivateError: " + message);
main/java/com/samourai/whirlpool/server/services/WebSocketSessionService.java: log.trace("(<) " + username + " connect");
main/java/com/samourai/whirlpool/server/services/WebSocketSessionService.java: log.trace("(<) " + username + ": disconnect");
main/java/com/samourai/whirlpool/server/services/MixService.java: log.warn("Rejecting already revealed username: " + username);
main/java/com/samourai/whirlpool/server/services/MixService.java: log.info("[" + mixId + "] " + username + " revealed output");
main/java/com/samourai/whirlpool/server/services/MixService.java: log.info("[" + mixId + "] " + username + " registered signature");
main/java/com/samourai/whirlpool/server/services/PoolService.java: log.info("[" + pool.getPoolId() + "] " + username + " removed 1 liquidity from pool");
main/java/com/samourai/whirlpool/server/services/PoolService.java: log.info("[" + pool.getPoolId() + "] " + username + " removed 1 mustMix from pool");
main/java/com/samourai/whirlpool/server/controllers/websocket/ConfirmInputController.java: log.debug("(<) [" + payload.mixId + "] " + username + " " + headers.getDestination());
main/java/com/samourai/whirlpool/server/beans/Mix.java: log.info("[" + mixId + "] " + username + " unregistered from confirming inputs");
main/java/com/samourai/whirlpool/server/controllers/websocket/RevealOutputController.java: log.debug("(<) [" + payload.mixId + "] " + username + " " + headers.getDestination());
main/java/com/samourai/whirlpool/server/controllers/websocket/SigningController.java: log.debug("(<) [" + payload.mixId + "] " + username + " " + headers.getDestination());
main/java/com/samourai/whirlpool/server/config/websocket/WebSocketConfig.java: log.debug("(<) " + username + " subscribe");
main/java/com/samourai/whirlpool/server/config/websocket/WebSocketConfig.java: log.debug("(<) " + username + " connect");
main/java/com/samourai/whirlpool/server/config/websocket/WebSocketConfig.java: log.debug("(<) " + username + " disconnect");
```
```
> grep log **/*.java | grep "ip="
main/java/com/samourai/whirlpool/server/services/RegisterInputService.java: log.warn("Rejecting banned UTXO: [" + banTO.get() + "], ip=" + ip);
```
Follow the money. Who owns the patent for that monstrosity!?
Absolutely! Not only that nut nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f should also publish their selection criteria. The phrase 'Feel free to apply again in the future' can feel like a bad joke if your projects have no real chance of being funded.
Take nostr:npub1v6qjdzkwgaydgxjvlnq7vsqxlwf4h0p4j7pt8ktprajd28r82tvs54nzyr and his Joinstr project, which combines privacy and decentralization, yet it didn’t receive a grant. Why? Is it because Bitcoin mixing is considered too controversial for the organization after the Samourai case?
'We have a minimum of 5 positive votes by the board for approval' sounds great but it says nothing about the reasoning behing those votes. It's like saying 'We've democratically decided to feed the cats but not the dogs', ok cool, but why?
That's just misleading propaganda. What I said is that your link to zerolink was wrong, just like that.
Here's the original ZeroLink protocol specification link: https://github.com/nopara73/ZeroLink. Although it's been superseded by WabiSabi, it remains historically significant.
You can use a Golomb-Rice encoded list then. It can encode all the PKs in a compact way and the relay can expand it without needing to use any other data source. It doesn't have errors and it is less cpu intensive, specially for the relay. Take it into account.
Oh I see, it is used as a compression mechanism then. It can work. Thanks for clarifying.
Sure, but that's only for new notes because you cannot query the database for historic notes using a BF.
According to the Zerolink specification, Wasabi was the first and only implementation (https://github.com/nostr:npub1qqvf96d53dps6l3hcfc9rlmm7s2vh3f20ay0g5wc2aqfeeurnh0q580c3j/ZeroLink). This was due to nostr:npub1qqvf96d53dps6l3hcfc9rlmm7s2vh3f20ay0g5wc2aqfeeurnh0q580c3j's design choice of registering a change address during input registration, whereas the Samourai team opted to move the change registration to the Tx0 transaction.
@SamouraiDev did make a valuable contribution to the Zerolink specs by fixing many typos in the original document (https://github.com/nostr:npub1qqvf96d53dps6l3hcfc9rlmm7s2vh3f20ay0g5wc2aqfeeurnh0q580c3j/ZeroLink/commits?author=SamouraiDev). But after that, the Samourai team decided to fork the repo, rename it as "Zeroleak," and then quickly realized it would be much easier to just steal the credit for @nostr:npub1qqvf96d53dps6l3hcfc9rlmm7s2vh3f20ay0g5wc2aqfeeurnh0q580c3j's work by claiming that Samourai was the real Zerolink all along.
We love Nostr as a publishing platform that offers unparalleled censorship resistance. But NIP44 does NOT provide most of the important qualities of e2e encryption:
- break-in recovery.
- repudiation (deniability).
- visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).
It's unclear whether it provides forward secrecy, but the spec implies that it does not - I might be wrong here.
We wrote this post about the qualities of e2e encryption and why they are important: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html
Excellent post!

