Show HN: UUID as a Service

http://uuid.me/

by ptramo • 14 years ago

13 24 14 years ago

uuid.me

ptramo6• 14 years ago

And there's a basic documentation for the "API" on https://github.com/pcarrier/uuidaas

This is obviously a joke.

zoowar• 14 years ago

Wrapper culture is pathetic.

rsyncinside• 14 years ago

Can you expand on your definition of "wrapper culture" (not to be confused with rapper culture)?

Because if I understand your meaning, your comment could be applied to pretty much the entire "www". Almost everything offered by a "server" or "as a service" is something that anyone can run on their own machine. Windows is on the decline, UNIX is taking over. It has come to pass. OSX, iOS, Android, ... all UNIX. All UNIX machines can be clients, servers, or both.

The idea that someone would believe such machines are limited only to being "clients" is... PATHETIC.

nodesocket• 14 years ago

This is a joke right?

ptramo6• 14 years ago

http://uuid.me/ifeelreallyreallylucky is giving it away.

thehodge• 14 years ago

A bit like my Number API, http://number-api.hodgetastic.com/, Open source at https://github.com/TheHodge/number_api

Outputs numbers in XML, CSV, JSON and as soon as it's deployed.. PDF

FigBug• 14 years ago

Why not just use http://wasteaguid.info?

gnosis• 14 years ago

Or, on Linux you could just type:

  uuidgen

gasda• 14 years ago

Why do I feel like I'm using up a UUID each time I run it.

amscanne• 14 years ago

If you don't want to bother with uuidgen:

    cat /proc/sys/kernel/random/uuid

shtylman• 14 years ago

the amount of code for this "service" is unfortunate

adamgravitis• 14 years ago

Indeed. There's even a name for the anti-pattern: "nanoservice".

http://soa.dzone.com/news/soa-anti-pattern-nanoservices

ptramo6• 14 years ago

Actually, I find pittsburgh's comment interesting. Nowadays every new piece of technology seems to offer HTTP and JSON support, but UUID support might be lacking, or its quality might be poor. Funnily enough that's the case for the Go standard library (compensated by an external module).

I could actually imagine someone trying to create UUIDs and not being bothered to implement that functionality correctly in their software.

I hope it'll never happen as relying on a third-party web service has really bad implications, but the world is ready now :)

FWIW, I added support for UUID sets in the API, so now one can ask for thousands UUIDs at once, if one ever needs to :)

As entertaining as this project has been for a few hours, it's time for me to move on.

mtrn• 14 years ago

Deployed such beast of a service myself once: http://www.uni-leipzig.de/~jobp/t-uuid.php

marc• 14 years ago

For anyone else wondering what this API is about:

It generates a (random) UUID. According to Wikipedia "the intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". Since the identifiers have a finite size it is possible for two differing items to share the same identifier. The identifier size and generation process need to be selected so as to make this sufficiently improbable in practice. Anyone can create a UUID and use it to identify something with reasonable confidence that the same identifier will never be unintentionally created by anyone to identify something else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve identifier (ID) conflicts.

One widespread use of this standard is in Microsoft's globally unique identifiers (GUIDs). Other significant uses include ext2/ext3/ext4 filesystem UUIDs, LUKS encrypted partitions, GNOME, KDE, and Mac OS X, all of which use implementations derived from the uuid library found in the e2fsprogs package."

Source: http://en.wikipedia.org/wiki/Universally_unique_identifier

chuhnk• 14 years ago

Twitter played with writing a UUID service a while back called Snowflake. https://github.com/twitter/snowflake

ptramo6• 14 years ago

Those are not UUIDs as in ISO/IEC 11578:1996 (GUIDs in the Microsoft world).

Obviously you can argue that the acronym applies correctly, but not its common understanding.

cnlwsu• 14 years ago

so.. with type 1 UUIDs with the mac address/timestamp you can generate 10,000 globally (providing you dont duplicate your mac address) unique ids per millisecond per system without conflict. With type 4 if just going random the chance of a collision is somewhere up there with having two of your data centers simultaneously hit with a meteorite (providing numbers are random) - although I suppose this would be useful if you are on a limited embedded system or something with no RTC or mechanism to generate static/random data and timestamps and random number generation is very unreliable. I assume this is a joke?

Mekza• 14 years ago

meaningless

ptramo6• 14 years ago

Well, that sounds like a UUID to me.

They have some internal semantics, but they're "only" designed to be "extremely likely unique", not tell a great story.

pittsburgh• 14 years ago

Whether or not this was built as a joke, there could be real benefit from a service like this.

Imagine you need a UUID in JavaScript. Here's a function that does it:

  function UUID() {
    return "4444-8888-FFFFFFFFFFFF";
  }

What's that you say? You want a randomly generated UUID? Okay, here's a clever one taken from http://stackoverflow.com/questions/105034/how-to-create-a-gu...

  'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
    var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
    return v.toString(16);
  });

That should be pretty good, right? Well, it's pretty good depending on your needs. If you need a UUID that is (practically) guaranteed to be unique within a single HTML document, and that UUID never leaves the scope of that page, then this function is a great solution. But if your client-side-generated UUID is sent to the server where it meets up with many other UUIDs generated from the same JavaScript code that ran in other browsers, then this function won't cut it. Why not? Because generating a random UUID in JavaScript relies on the use of Math.random(), which in most browsers uses the current datetime as a seed, and that's only a fine seed if you're building Tetris.

Given enough time, two browsers will eventually generate a UUID at the same moment, meaning they both use the same seed and therefore generate the same UUID.

So, why not seed a pseudo-random number generator in JavaScript yourself with something better than the current time? Because client-side JavaScript doesn't have access to good sources of entropy. Within the browser, your sources of entropy are limited to things like the current time, the window dimensions, the user agent string, the number of plugins installed, etc. You could capture mouse movements and keyboard clicks over time, but it would take a while to generate sufficient entropy for a cryptographically secure random number. Also, if you need to generate a UUID on page load you can't wait for the user to jiggle their mouse.

Meanwhile, the server has access to better sources of entropy. For example, many /dev/random implementations use the time between hard drive seeks as a source of entropy. Of course this entropy pool would be exhausted quickly, but you could replenish the pool with outside sources of entropy such as white noise from a radio ( https://www.random.org/history/ ) or even radioactive decay ( http://www.fourmilab.ch/hotbits/ ).

I don't know what sources of entropy http://uuid.me is using to generate random UUIDs, but it might be better than what JavaScript is capable of on its own. If uuid.me served its UUIDs in JSON, then you could make a JSONP call in JavaScript, providing you with a UUID that is much less likely to ever collide with another client's UUID.

ptramo6• 14 years ago

It does serve them in JSON if you ask for it. The API on github gives stupid examples, but it can be used reasonably.

One can use http://uuid.me/v1.json or http://uuid.me/v4.json

At least v4 will use Java's SecureRandom, and my server is running a recent Oracle JVM7, so I would argue that the randomness should be decent enough. Maybe not perfect, but good enough to make collisions extremely unlikely.

That being said, this service really was written as joke. Particularly the JSON and XML outputs.

As to /dev/random, no, it's not simply derived from time between hard drive seeks (at least for the operating systems I care about).

rachelbythebay• 14 years ago

ns2.entrydns.net seems to be unable to give authoritative answers for uuid.me. If it doesn't load at first, that's probably a big part of it.

kennu• 14 years ago

One related topic that I find interesting is how some programmers feel compelled to make a pivotal distinction between "unique" and "practically unique" with regards to random UUIDs. They refuse to insert UUIDs into a database blindly, even if checking for duplicates implies a heavy performance penalty or even makes scalability impossible.

Personally I compare this distinction to something like the odds of the Earth being destroyed by a meteor. It could happen and it would be a disaster, but the probability is so low that I just decide not worry about it.

So the interesting question is: Which one is the better programmer, the one who trusts "practically unique" or the one who always requires "unique"?

Show HN: UUID as a Service

Related Stories