12 Likes
Want to watch the Town Hall video on Tardigrade? Here’s your link!
8 Likes
It was so lovely to hear Jocelyn’s voice! 
2 Likes
awww. thanks! thats a nice compliment
2 Likes
those link names tho…
the townhall said there where 180mil objects stored…
the url being alphanumeric so 35 symbols
and 35^6 is 1838265625 ergo with only 6 symbols it would be possible to sort 10 times that.
and the number of symbols in those tardigrade urls would most likely give enough options to be able to stort every atom in the milkyway with its own unique identifier, if not the known universe…
which leads me to wonder if there is a reason for it, because it sure seems slightly overkill…
they might do well in a more human readable shortened format or some such thing.
2 Likes
yes, the link is quite long currently, and I was actually discussing it today with our VP of Engineering, JT Olio…keep an eye on the project for good developments coming up!
3 Likes
Maybe you could use a system similar to what git does?
Git allows you to use only the first characters: if it matches only one file, return it.
If not, error out and ask for more…
Or make it possible to use custom aliases.
But I agree with @SGC, there is room for improvement 
3 Likes
Remember that Tardigrade is an end-to-end encrypted solution. This long URL actually contains a full “access grant” to the video file. The access grant contains the following information:
- Address to the satellite that stores the metadata of the file (i.e. which storage nodes have the pieces of the file)
- The macaroon (an access permission proof) that allows accessing this specific video file.
- The encryption key to decrypt the video file.
The macaroon and the encryption key are not stored on the satellite, so they need to be embedded in the URL.
5 Likes
my only real problem with it, is that it’s ugly and hard to work with.
so setup a url redirection server/redundant cloud service that handles those links and makes the url human friendly.
have you tried to actually work with those url’s
could you paste them into any CMS, do the share well on facebook… how difficult is it if you copied the link and closed the site and then paste it twice… just so annoying.
how hard is it to fix that… i understand what you are saying, but my issue is that urls that long is just hell in so many ways…
it might be needed, but success is ease of use… to long url’s for uploaded stuff might affect avg end user opinions of the service…
i duno how best to fix it, i just know i shouldn’t be like that, it’s way to much… nobody does that… for good reason.
1 Like
There are tons of URL shortening services out there. Including open source that you can host yourself.
At this moment, we want to avoid storing people’s access grants in a database of our own URL shortening service. This would create a honeypot of secrets that would attract potential hacker attacks. It’s one more thing to operate securely.
We leave it to the user to decide if they need shorter URLs and use any of the available public URL shortening services, or host their own for maximum security.
8 Likes
good and very valid counter argument…
and for now maybe good enough, but still it doesn’t take much for some users to not like a service, it’s not just for ascetics… so atleast long term its something that could be dealt with…
ofc finding a great solution that fulfills all requirements can take a long time, but one won’t find it if ones isn’t atleast passively looking for the solution.
and i don’t think it’s the users concern to think about the user experience tho
2 Likes
So, we did have a good discussion here about link shortening, but in it we missed talking about one important point, which is that we were about to launch link shortening! Here is the townhall link again in its new format:
Shorter, eh? See We're launching Linkshare short URLs and static site hosting! for the announcement.
(Kaloyan had a great point earlier up about avoiding making a honeypot of secrets. We have tried to avoid this with this link shortening system. The way this works is jvgihxcuwlxv2o26duuiohfbk6ya is actually a Base-32 encoded encryption key for the original longer URL. We store the original longer URL encrypted, identified by the hash of the encryption key. When we receive a shortened URL, we hash this shortened key, find the encrypted, longer access grant, then use the shortened key to decrypt it. What this means is we actually can’t load or decrypt these saved access grants until someone actually accesses them, making this much less honeypot-like. The link sharing server is doing the decryption of the file content server-side still, so we intend to work through full end-to-end encryption (javascript, client-side) later).
6 Likes
2 Likes
Personally I think a “folderesque” structure is a weakness because it reveals the folder structure you use in your bucket, so you always have to think about “how will people react to my folder structure? Are the names good?” instead of just sharing the filename.
But my only experience with sharing files is through nextcloud so that’s a bit different. Very possible there are good reasons to have a folder structure in the link.
However, I like that the link is a lot shorter now!
3 Likes