search

hashids / hashids.github.io

This is the old Hashids website. It is no longer maintained and has migrated over to Sqids.
https://sqids.org
206 stars 34 forks source link

Moving forward to 1.0 #1

Closed jd327 closed 10 years ago

jd327 commented 10 years ago

Hey guys,

tl&dr: 1) new website 2) moving to v1 and a few adjustments 3) might be a good time to rename hashids 4) skip to the bottom to answer two questions.

I've been meaning to cleanup a few things on Hashids for a while, so finally got around to it. I created this github Hashids org and started freshening up the website a bit (http://hashids.github.io/ 90% done). The site will be on Github now (repos will of course stay where they are), so all of you can update the site/documentation as you need. I'll repoint hashids.org to it when it's ready.

New things on the website:

I think the lib is ready to move to 1.0. The algorithm is small enough and fast enough that I don't see anything else we need to update (although maybe handling of big ints later on). For now only a few minor adjustements:

"Hashids" as the name, serves well in terms of traffic and what people search for. But it's a tiny bit misleading since hashes cannot be decrypted, and yet it's in the name - so there's some user confusion there. That's my fault. I didn't initially realize this was going to be such an issue, but the more the project grows - the more people wonder about that.

So, since 1.0 is coming, maybe this is a good time to move to a different name. This is where I need your feedback. Alex @alco has named his Elixir repo "saltie", and I thought that was really simple + easy to remember. I liked it when I saw it. (saltie.org is available too.)

Some of the disadvantages of renaming that I can think of:

But the advantages are that it might be cleaner, "catchier" and easier to remember in the long run. On the other hand, a lot of people (including myself) have already gotten used to the name Hashids. So, I want to hear what you have to say. Please give feedback to the following 2 issues as we make the short jump to 1.0:

(edit: trying to figure out how to get you guys to see this issue, nvm this line. @speps @ullmark @fanweixiao @davidaurelio @peterhellberg @zakame @jofell @schoentoon @leihog @dswitzer @alco @cmaron)

  1. Do you think we should rename the project to Saltie, or keep it as Hashids?
  2. Are there any urgent changes you'd like to see in 1.0? (if not urgent, they can wait till >1.0)
dswitzer commented 10 years ago

I do agree the name is a misleading (for the reasons you mention), but it doesn't really bother me. There will be always purist out there that will be turned off just by it's name, but I'm not sure I would have notice this project originally if it was called "Saltie". It was the name "Hashids" that jump out to me.

I'm good with whatever you decide. :)

davidaurelio commented 10 years ago

  1. I agree with @dswitzer – I don’t think the name is a real problem, but if you really want to change the name it shouldn’t be a problem.

    The name switch to “saltie” would make it possible to re-align the version number of my python package with the JavaScript version again, since I’m already at 1.0.0 and will push to 2.0.0 due to the algorithm changes. Having both packages at 1.0.x might make it easier to integrate the JS + py implementations for users of the library.

    After having done a rather blind port of the JS code the last time, I will take the time to get a deeper understanding of the algorithm for the next version, so maybe the code can become more “pythonic”. Although nobody has complained yet.

  2. I don’t have any suggestions for changes…

The new site is looking good btw, and it’s great that you have added more explanations about the algorithm.

alco commented 10 years ago

Since we are talking about synchronising versions, I'd like to bring to your attention the following issue. JavaScript has only floating point numbers (IEEE-754 64bit) which means it can precisely represent integers of the absolute value at most 2^53. However, many ports to languages that have native 64 bit integers or arbitrary size integers will use those respective types for ids. This will lead to diverging behaviour between implementations.

Here I just took a few sample inputs and ran them with the JS and Python implementations - https://gist.github.com/alco/54beac75f1188bbe280b.

How can this be solved?

  1. By implementing unsigned 64-bit or arbitrary-size integer support in the JS, Lua (both use floats), PHP (uses signed ints), Perl (seems to use floats too) versions.
  2. By forcibly limiting the range of allowed inputs to be below 2^53 or 2^32. In the latter case, the implementations with native integers can use 32-bit unsigned integer type.
  3. By allowing to pass ids as strings and using a few smart tricks in the implementation (e.g. representing large ints as pairs of 32-bit integers) to do arithmetic on them.
speps commented 10 years ago

I would also prefer to keep Hashids, just because renaming introduces more confusion than anything. Personally, although that might be very judgmental, when I see a project being renamed I think it's because it has troubles, lacks direction or something (which is not the case of course). I'm all for keeping Hashids.

I'm not sure about the changes to 1.0 as I didn't keep up to date with Hashids since I first created the Go version but I'll try to update it anyway as soon as possible.

On 23 August 2014 10:47, Alexei Sholik notifications@github.com wrote:

Since we are talking about synchronising versions, I'd like to bring to your attention the following issue. JavaScript has only floating point numbers (IEEE-754 64bit) which means it can precisely represent integers of the absolute value at most 2^53. However, many ports to languages that have native 64 bit integers or arbitrary size integers will use those respective types for ids. This will lead to diverging behaviour between implementations.

Here I just took a few sample inputs and ran them with the JS and Python implementations - https://gist.github.com/alco/54beac75f1188bbe280b.

How can this be solved?

  1. By implementing unsigned 64-bit or arbitrary-size integer support in the JS, Lua (both use floats), PHP (uses signed ints), Perl (seems to use floats too) versions.
  2. By forcibly limiting the range of allowed inputs to be below 2^53 or 2^32. In the latter case, the implementations with native integers can use 32-bit unsigned integer type.
  3. By allowing to pass ids as strings and using a few smart tricks in the implementation (e.g. representing large ints as pairs of 32-bit integers) to do arithmetic on them.

— Reply to this email directly or view it on GitHub https://github.com/hashids/hashids.github.io/issues/1#issuecomment-53148326 .

davidaurelio commented 10 years ago

JavaScript has only floating point numbers (IEEE-754 64bit) which means it can precisely represent integers of the absolute value at most 2^53. However, many ports to languages that have native 64 bit integers or arbitrary size integers will use those respective types for ids. This will lead to diverging behaviour between implementations.

That’s a valid concern. I’m not sure about the best solution.

ullmark commented 10 years ago

Must say that I agree that a name change probably only confuses people.

fanweixiao commented 10 years ago
  1. I'd like to keep Hashids naming, although hash really should not have a decrypt method.
  2. Should we adding more ID support like MongoDB id? ( https://github.com/jiecao-fm/hashids-java/issues/6), it seems not a general usage senario, but this made Hashid easy to integrated to.

Best regards, C.C. （范维肖）| 维生素CC | mobile: 13810361720

On Tue, Aug 26, 2014 at 12:49 AM, Markus Ullmark notifications@github.com wrote:

Must say that I agree that a name change probably only confuses people.

— Reply to this email directly or view it on GitHub https://github.com/hashids/hashids.github.io/issues/1#issuecomment-53290433 .

jd327 commented 10 years ago

Ok guys, perfect.

@davidaurelio, would it be possible for you to move up to 1.0.2 when we move all to 1.0? Thanks re: site. @alco, that's an important topic - I'm going to move it out to its own issue. @fanweixiao, hehe didn't think non-JS devs would want support for hex->hashids (re: Mongo). I initially was going to have it just in the Node repo, but I guess it would make sense to support encodeHex/decodeHex among all implementations -- it's a pretty tiny addition.

Alright, so here's what I'm going to do:

  1. Keep the name Hashids. I'm also going to add a paragraph to the website to have that bit about hashes & decryption.
  2. Alex's big ints topic - moving it out to another issue. Would be good to handle that properly in v1.1. Edit: https://github.com/hashids/hashids.github.io/issues/2
  3. Since we're keeping the name, I'll update hashids.org in the next few days. Still have some minor changes to make there.
  4. I'll move js,node,coffee,php to v1.0 first and then create issues in your repos to update yours. Of course I'll update the changelog. If you're already at 0.3.*, changes should be minimal. I understand all of you are in tech, which means you're busy for at least the next 2.5 years. So, you guys feel free to update them at your own pace, and let me know if I can do anything to help.

Thank you all for your feedback, Ivan

peterhellberg commented 10 years ago

Sounds good to me, but shouldn’t the new site use a responsive design? (The table of language versions is garbled on mobile for example, and lots of horizontal scrolling)

Good job so far though :)

On Monday, August 25, 2014, Ivan Akimov notifications@github.com wrote:

Ok guys, perfect.

@davidaurelio https://github.com/davidaurelio, would it be possible for you to move up to 1.0.2 when we move all to 1.0? Thanks re: site. @alco https://github.com/alco, that's an important topic - I'm going to move it out to its own issue. @fanweixiao https://github.com/fanweixiao, hehe didn't think non-JS devs would want support for hex->hashids (re: Mongo). I initially was going to have it just in the Node repo, but I guess it would make sense to support encodeHex/decodeHex among all implementations -- it's a pretty tiny addition.

Alright, so here's what I'm going to do:

  1. Keep the name Hashids. I'm also going to add a paragraph to the website to have that bit about hashes & decryption.
  2. Alex's big ints topic - moving it out to another issue. Would be good to handle that properly in v1.1.
  3. Since we're keeping the name, I'll update hashids.org in the next few days. Still have some minor changes to make there.
  4. I'll move js,node,coffee,php to v1.0 first and then create issues in your repos to update yours. Of course I'll update the changelog. If you're already at 0.3.*, changes should be minimal. I understand all of you are in tech, which means you're busy for at least the next 2.5 years. So, you guys feel free to update them at your own pace, and let me know if I can do anything to help.

Thank you all for your feedback, Ivan

— Reply to this email directly or view it on GitHub https://github.com/hashids/hashids.github.io/issues/1#issuecomment-53340381 .

Peter Hellberg Ruby Developer, Code7 Interactive

jd327 commented 10 years ago

@peterhellberg working on it :)

jofell commented 10 years ago

Hi guys,

I also suggest to keep the name and will start work on moving to v1.0. Will also incorporate a podspec for the library.

Sorry for the late reply.

On Tue, Aug 26, 2014 at 1:36 PM, Ivan Akimov notifications@github.com wrote:

@peterhellberg https://github.com/peterhellberg working on it :)

— Reply to this email directly or view it on GitHub https://github.com/hashids/hashids.github.io/issues/1#issuecomment-53377386 .

Jofell S. Gallardo www.jofell.com

Founding Engineer Bandwagon - iTunes backup application www.ridethebandwagon.com

davidaurelio commented 10 years ago

@davidaurelio, would it be possible for you to move up to 1.0.2 when we move all to 1.0?

Of course that would be possible, but I would like to avoid that to keep versioning predictable for users (I’m a fan of Semantic Versioning)

In this sense, I’d like to increase the major version each time changes are introduced that are not backwards compatible. I’ll have to live with the version offset, b/c I went to 1.0.0 way too early. I guess the problem is smaller than creating confusion for existing library users.

zakame commented 10 years ago

+1 on keeping Hashids, although Saltie seems clearer (for me.)

ullmark commented 10 years ago

And, if I may, on the .NET page, linking to the other .NET implementation and just saying "Hashids 0.3" is a bit confusing since my package also supports 0.3. The reason for them not forking but copying the code and make alterations to it still eludes me.

His repo support Int64 though, which is something that's still being discussed how to handle :)

davidaurelio commented 10 years ago
  • changing naming back to encode/decode (instead of encrypt/decrypt; more appropriate + discourages people from encoding sensitive data)

So this is happening anyways? That could allow me to go to v1.1.0 by keeping encrypt/decrypt for the “old” (0.3) behavior and exposing the new algorithm with encode/decode. I’m not entirely sure whether that’s a great idea, though. Maybe that would be even more misleading.

jd327 commented 10 years ago

So, initially it was actually encode/decode, but I switched it to encrypt/decrypt somewhere in 0.3.

The problem is a) I'm not sure having only a consistent shuffle based on salt qualifies as an encryption algorithm (at least a true one) and b) I noticed people starting to use hashids on sensitive data (after all if it's encrypt/decrypt, then why not?)

So I want to encourage people to use it for what it was designed for in the first place. That's why it might be more appropriate to move it back to encode/decode.

fanweixiao commented 10 years ago

Should we consider throw exception when encrypt number larger than 2^53 ?

jd327 commented 10 years ago

@fanweixiao there's another issue for this: https://github.com/hashids/hashids.github.io/issues/2 we'll handle large ints after 1.0

fanweixiao commented 10 years ago

@ivanakimov OK, gotcha!