Custom slugs for geobins

[aaronpk]

Add "Create this bin" option to bins that are 404.

I should be able to type a URL like http://geobin.io/test and see "Create this Geobin" instead of "Create a new Geobin". This makes it more consistent with sites like talky.io or wikis.

[aranasaurus]

The issue that @courtf brought up when we talked about doing this is we don't have any kind of security protecting your bin. So if multiple people wanted to use test at the same time, they could, and they'd just both be seeing extra data flowing into their bin which might be a bit of surprise.

[aaronpk]

That is also quite possibly a feature.

[aranasaurus]

Fair enough... we'd definitely need to put some verbiage somewhere that prominently warns people of said "feature" though.

:walking: :musical_note:

[aaronpk]

Agreed. Probably something like "Anyone with this URL can send and view the data sent to it".

For reference, talky.io says "Others can join you just by going to https://talky.io/test"

[ungoldman]

I think this is a valid request. @courtf is concerned about possible collisions, e.g. a bunch of people overusing http://geobin.io/test, but if it's wide open then the onus is on the user as long as we make it clear how the site functions. The possibility of collisions is still there with random URLs, just extremely unlikely. I asked @courtf to limit bin IDs to 10 characters because a full UUID in a URL seems like overkill.

[aaronpk]

Let's go for it. As long as it's clear that there is no access control on bins, it should be fine.

fwiw a 10-character string of [a-zA-Z0-9_] is about equivalent to a 128-bit UUID.

[aranasaurus]

The way I implemented this in #115 doesn't add a button, rather just shows the empty bin page (the "No history yet" page with the sample curl). I like it this way better, really, and am considering just changing the text on the no history page a little to accommodate.

Any objections?

[aaronpk]

Yeah sounds good. I like the idea that all from the user's perspective, all bins exist all the time.

[ungoldman]

Me too! From a user perspective it's not the bin expiring, it's the data. In fact that may be useful from the point of view of how we store & retrieve things in redis.

[aaronpk]

Ironically, Redis works the same way. pub/sub channels just "work", they don't need to be created. You can always add things to lists whether or not you've "created" a list. I like the way that ends up feeling.

[ungoldman]

I think we're explicitly setting a bin to expire after 48 hours now. That's reflected in the UI (there's a piece of text indicating when the bin will expire in the bin dropdown and on the front page). If we're rethinking this then we need to rethink the UI as well -- do we indicate that individual pieces of data have an expiration date? or do we keep everything in there and renew the bin's expiration date on each view?

[ungoldman]

If we do the latter or even stick with the current model we still need to explain it to the user -- I'm noticing the whole expiration concept isn't really covered very well on the front page.

[aaronpk]

Renewing the expiration every time data is sent would make more sense than every view. Renewing every view is not a good idea because then bins would basically last forever, like if they start getting crawled by search engines. That said, that also has the potential to create lots of data sticking around. If you can think of a good way to indicate that individual pieces of data disappear after 48 hours that would be awesome.

[aranasaurus]

Yeah, the UI is where I stopped in the PR, because I realized it was more than just changing text.

I think we should rework the UI a bit, but not too much. I think the smallest amount of change to the Your History stuff would be to just change the Expiration label to be "Data Expiration" or something similar and have it do the same thing that it is doing now (showing when the latest piece of data in the bin will expire). The other option is to remove the Expiration column (or change it to Last Updated and make it the date of the last data received), and then have each item in the Bin view indicate when it expires, which wouldn't be very difficult on the backend, but would require a bit of thinking on the front end.

As @ngoldman said, either way, we need to add something about data expiration to the front page. We also need to add something there about the visibility/privacy of data as stated in the beginning of this issue's comments thread.

I don't think we should be updating expiration on views, geobin is not a tool for creating anything permanent. The custom binIDs feature may make it seem like we're making something permanent, but in reality we're just making it more flexible and easy to use for its intended purpose: as a debugging tool. These changes make it so that you can put your custom binID in your app just once and not have to worry about updating it every 48 hours.

[ungoldman]

@aranasaurus Agree, let's do it this way and iterate further as time allows!

[ungoldman]

ah, we had such big dreams when we were younger