Show HN: Share It, Anonymously with Self Destruct Messages

Love the idea. I ll implement : )

Thanks for visioning better !

Its the haunt of existing premiums that drove me to make this. :)

Literally free : )

> why Signal can't be implemented as a completely offline-first/PWA web-app.

Because some people want and/or need the things you said to just throwaway.

> The problem with web apps is that doing timing sensitive stuff such as encryption and decryption in javascript is risky and difficult. Javascript also takes a serious toll on performance and battery life.

This feels like somewhere WebAuthn and/or Emscripten/WASM help a little bit here? I'm most worried about vulnerabilities to the underlying protocol and less about perf/battery life (maybe some side-channel attacks?).

> I'm assuming "completely offline" means that it still sends some data somewhere, otherwise the messenger wouldn't make any sense.

Yes, I did a bad job of explaining this, but online-when-you-need-to-be. "offline" was meant to mean "offline-first", a common frontend terminology for PWAs.

> Adding encryption (proper encryption) to the Telegram client would net you a fully native experience that works cross-platform without issues. Going native also allows you access to stuff like TPMs, although you can assume most desktop machines still don't have them. You also have much more control over the security properties of the code if you stick to native code.

> The folks over at Matrix are experimenting with running their Matrix servers in a peer to peer configuration on the device itself. Stuff that server into a cross platform client like Fluffychat or Element and you've got yourself a chat app with federation and cross platform chat support without relying on any specific server.

Well that would be great, I'd love to just do that.

> If you want to stick to a browser only solution, I'm not entirely sure how you'd go about making that talk to other clients. IPFS requires access to a third party gateway, as do most peer to peer solutions. I think you can make WebRTC work as a means of full P2P through a DHT but I'm not entirely sure how.

I think you can get away with signaling (STUN/TURN) here -- if you have WebRTC you can go STUN-only and even if you have to TURN if you're sending encrypted data then it shouldn't matter. Honestly I think IPFS is actually overkill for this (though it has it's upsides), the only technology you really need for this to work is WebRTC + a STUN/TURN server.

> The problem with a simple, offline, encrypted chat client is that it's not simple. Security is very hard; if you're willing to give that up, there's plenty of IRC web clients for you to choose from. If you've got any good ideas on how to build this, I encourage you to work it out and make a proof of concept, because it sounds like it could be very useful.

But at this point we have methods that work, there's no need to rethink the primitives, we've got good well-tested schemes for sending simple messages. In the desktop world simply gpg encrypting and sending files is good enough (even a basic scheme with asymmetric crypto + nonce + symmetric key + symmetric crypto), why is messaging so hard as to be unattempted even in the 1-to-1 case?

Maybe the only way for this to really get it's tired kicked is to just build the thing in a weekend (if I'm right about it being so simple then it "should" be easy, right?) and post it to HN.

It was over 20 years ago now, and I don't remember which library it was, but I ran across a type-1 UUID library that stored the timestamp of the latest UUID it handed out in a static (or maybe thread-local, I forget) variable, and would nanosleep until the system clock next ticked if it had already handed out a UUID with the current timestamp. So, you were limited in your UUID generation rate by the resolution of the system clock.

(I guess the fear was that it was theoretically possible for the process to crash and come back up with the same PID/TID within the same system clock tick, if the machine were really chewing through processes rapidly. It's good, as they aren't called Nearly Unique IDs, and the main use for type-1 UUIDs would be if you're paranoid about RNG collisions, but it does limit you to one ID per system clock tick, even though the timestamp in the type-1 UUID is actually 100-nanos resolution.)

A better solution would have been to query the system clock resolution, at library initialization time check the current system timestamp, and use the low bits of the type-1 UUID timestamp as a counter, being careful to never catch up to the current time. The library wouldn't have been able to hand out any UUIDs during the first system clock tick after library initialization, but after that, it could hand out up to 10 million UUIDs per second per thread. If that's not fast enough, one could also have it check for multiple network cards and use a pool of MAC addresses instead of just the primary interface's MAC address.