Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every GitHub object has two IDs

greptile.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Every GitHub object has two IDs

#11

Post by krisoft »

agwa wrote: post #4

> GitHub's migration guide tells developers to treat the new IDs as opaque strings and treat them as references. However it was clear that there was some underlying structure to these IDs as we just saw with the bitmasking Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally enc…

> Great, so now GitHub can't change the structure of their IDs without breaking this person's code.

And that is all the fault of the person who treated a documented opaque value as if it has some specific structure.

> The lesson is that if you're designing an API and want an ID to be opaque you have to literally encrypt it.

The lesson is that you should stop caring about breaking people’s code who go against the documentation this way. When it breaks you shrug. Their code was always buggy and it just happened to be working for them until then. You are not their dad. You are not responsible for their misfortune.

> I find it really demoralizing as an API designer that I have to treat my API's consumers as adversaries who will knowingly and intentionally ignore guidance in the documentation like this.

You don’t have to.

Re: Every GitHub object has two IDs

#12

Post by maxbond »

haileys wrote: post #10
maxbond wrote: post #9

Earlier quoted context omitted.

You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.

Encoding a type name into an ID is never really something I've viewed as being about performance. Think of it more like an area code, it's an essential part of the identifier that tells you how to interpret the rest of it.

That's fair, and you could definitely put a prefix and a UUID (or whatever), I failed to consider that.

Re: Every GitHub object has two IDs

#14

Post by perfmode »

agwa wrote: post #4

> GitHub's migration guide tells developers to treat the new IDs as opaque strings and treat them as references. However it was clear that there was some underlying structure to these IDs as we just saw with the bitmasking Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally enc…

The API contract doesn’t stipulate the behavior so GitHub is free to change as they please.

Re: Every GitHub object has two IDs

#15

Post by pdpi »

maxbond wrote: post #9
haileys wrote: post #7

Earlier quoted context omitted.

This is well understood - Hyrum's law. You don't need encryption, a global_id database column with a randomly generated ID will do.

You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.

XOR encryption is cheap and effective. Make the key the static string "IfYouCanReadThisYourCodeWillBreak" or something akin to that. That way, the key itself will serve as a final warning when (not if) the key gets cracked.

Re: Every GitHub object has two IDs

#16

Post by bigblind »

agwa wrote: post #4

> GitHub's migration guide tells developers to treat the new IDs as opaque strings and treat them as references. However it was clear that there was some underlying structure to these IDs as we just saw with the bitmasking Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally enc…

I think more important than worrying about people treating an opaque value as structured data, is wondering _why_ they're doing so. In the case of this blog post, all they wanted to do was construct a URL, which required the integer database ID. Just make sure you expose what people need, so they don't need to go digging.

Other than that, I agree with what others are saying. If people rely on some undocumented aspect of your IDs, it's on them if that breaks.

Re: Every GitHub object has two IDs

#17

Post by lelandfe »

maxbond wrote: post #6
agwa wrote: post #4

> GitHub's migration guide tells developers to treat the new IDs as opaque strings and treat them as references. However it was clear that there was some underlying structure to these IDs as we just saw with the bitmasking Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally enc…

You could also say, if I tell you something is an opaque identifier, and you introspect it, it's your problem if your code breaks. I told you not to do that.

Once "you" becomes a big enough "them" it becomes a problem again.

Re: Every GitHub object has two IDs

#18

Post by taftster »

phibz wrote: post #13

In database design typically it recommends giving out opaque natural keys, and keeping your monotonically increasing integer IDs secret and used internally.

Maybe. Until your natural key changes. Which happens. A lot.

Exposing a surrogate / generated key that is effectively meaningless seems to be wise. Maybe internally Youtube has an index number for all their videos, but they expose a reasonably meaningless coded value to their consumers.

Re: Every GitHub object has two IDs

#19

Post by Retr0id »

pdpi wrote: post #15
maxbond wrote: post #9

Earlier quoted context omitted.

You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.

XOR encryption is cheap and effective. Make the key the static string "IfYouCanReadThisYourCodeWillBreak" or something akin to that. That way, the key itself will serve as a final warning when (not if) the key gets cracked.

Any symmetric encryption is ~free compared to the cost of a network request or db query.

In this particular instance, Speck would be ideal since it supports a 96-bit block size https://en.wikipedia.org/wiki/Speck_(cipher)

Re: Every GitHub object has two IDs

#20

Post by maxbond »

pdpi wrote: post #15
maxbond wrote: post #9

Earlier quoted context omitted.

You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.

XOR encryption is cheap and effective. Make the key the static string "IfYouCanReadThisYourCodeWillBreak" or something akin to that. That way, the key itself will serve as a final warning when (not if) the key gets cracked.

A cryptographer may quibble and call that an encoding but I agree.
Post reply on HN