Live data from Hacker News

Show HN: Share It, Anonymously with Self Destruct Messages

pastenow.me

61–68 of 68 posts

Re: Show HN: Share It, Anonymously with Self Destruct Messages

#61
Love these utility service. A couple of things I noticed:

- It's not immediately clear that the message will self destruct from creation or starting from recipient opening it.

- I created a test note and it says: "Expiring in a few seconds" but not even a minute has passed.

- It would be nice to have some reference in the footer with some terms and who made this site.

Re: Show HN: Share It, Anonymously with Self Destruct Messages

#62
post #49

Earlier quoted context omitted.

Any resource about this? Someone mentioned it before and it seems false. UUIDS are made to scale and i think it's mostly about a lack of understanding of UUIDS. Eg. some versions of UUIDS are meant to be deterministic, some for sortability, ... https://en.m.wikipedia.org/wiki/Universally_unique_identifie...

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…

It was only proposed as a standard in 2005. So perhaps the first versions of it were not efficient?

I definitely didn't had issues the last 10 years ( .net )

Re: Show HN: Share It, Anonymously with Self Destruct Messages

#63
post #49

Earlier quoted context omitted.

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…

It was only proposed as a standard in 2005. So perhaps the first versions of it were not efficient? I definitely didn't had issues the last 10 years ( .net )

The UUID RFC is from 2005, but they're also documented in the ISO/IEC 11578:1996 standard.

As I mentioned, a good type-1 implementation uses a counter to simulate a higher resolution system clock to get around the system clock resolution limiting scalability. Also, I'm guessing you're generating type-4 (random) UUIDs instead of type-1 (MAC address and timestamp), right?

My point is that if you're generating UUIDs rapidly, check that you're either generating type-4, or that you're using a high-quality type-1 implementation that simulates a higher resolution clock using a counter.

Re: Show HN: Share It, Anonymously with Self Destruct Messages

#65
post #56
post #44

Earlier quoted context omitted.

What's wrong with the cryptpads? Anyway, a bit of feedback: 1. You really need a privacy policy 2. Instead of very long hexadecimal UUIDs use shorter IDs with more valid characters. Do you really need 128 bits for something that has to be brute forced and only lives for a limited time? Perhaps 64 bits are sufficient?

2) what would shorter IDs accomplish?

Typing URL onto mobile?

Re: Show HN: Share It, Anonymously with Self Destruct Messages

#67

Love these utility service. A couple of things I noticed: - It's not immediately clear that the message will self destruct from creation or starting from recipient opening it. - I created a test note and it says: "Expiring in a few seconds" but not even a minute has passed. - It would be nice to have some reference in the footer with some terms and who made this site.

Duly noted. will update with tons of feature (that community suggested) this weekend :)
Post reply on HN