Google devs try to create new global namespace Wouldn't it be nice if there was a universal and consistent way to give names to files stored on the Internet, so they were easy to find? A universal resource locator, if you like? The problem is that URLs have been clunkified, so Upspin, an experimental project from some Google engineers, offers an easier model: identifying …
ann@example.com is a unique identifier (within the internet as we know it) so I assume that this address is used to send the initial private keys to 'Ann'. After that, is the existence of the email address and service needed? What happens if example.com goes bust and Ann loses that email service?
Anyone with half a brain tries not to publish their email address on line, so that the spambots do not find it. This proposal would therefore appear to be an invitation to spam the user into oblivion, assuming that the associated mailbox might actually need to have a human attached to it.
So create a fake email address. Or an account specifically designed to handle Upspin related messages.
Yes the latter will get spammed but you can probably ignore it for the most part and let the spam just fester on the server. If someone has a good reason to contact you about your Upspin shares they can use your legitimate email address or other contact channel. If they don't know what they are..well maybe there's no good reason for them to be contacting you anyway ;)
Except of course that "create a fake email address" is not the answer, just a very, very shit workaround to an inherent problem in the product that must be fixed before implementation.
.....and one that 99.99% of people won't either know how to or bother doing. It's a spamfest waiting to happen.
From the brief description in the article, it looks like an attempt to reinvent the ISO standard on digital object identifiers. At least that one works very well indeed; it also nicely solves the problem of having an immutable object identifier without forcing an immutable underlying provider or location.
See: https://www.doi.org/
This post has been deleted by its author
And/or plain old URLs?
Maybe I missed the critical bit where it tells me how this Upspin thing is completely different from any other system where users can upload files to their own space and give links to those files?
What is so fantastically new and amazing about using e.g. 'doctor_wibble@example.com/smuttyp0stcards.zip' instead of 'example.com/doctor_wibble/smuttyp0stcards.zip' that is not exactly how things have been done before?
Did I miss the revolutionary step somewhere or is that the 'with an app' bit? Or is it that people are allowed to create folders again?
(post rewritten to avoid unclarity, hopefully less fail this time)
What is so fantastically new and amazing about using e.g. 'doctor_wibble@example.com/smuttyp0stcards.zip' instead of 'example.com/doctor_wibble/smuttyp0stcards.zip' that is not exactly how things have been done before?
The main advantage is in being able to disassociate the file from where it is held. It seems for once I am at the bleeding edge, having just implemented an "@name/file.ext" scheme for a local content delivery system.
In your case, what happens if "doctor_wibble@example.com" is your email address, but you move all your files over to "cheaphosting.com"? There are ways to map "'example.com/doctor_wibble" to "'cheaphosting.com/users/doctor_wibble, but the "@name/file.ext" is easy to do, understand and pass around. It also allows access via this identifier and to the original and actual site locations. Where "@name/..." should redirect to can be handled automatically with servers propagating whose files they hold to a central lookup server.
I think the answer is; it's not that much of a big deal, but does have its uses. I'm happy with the concept on the local net I am using it on (and it doesn't have to be used, it's optional) but not so sure about a global roll-out and using email addresses as personal identifiers.
Fair enough, and I do get how it works, I just don't see it as especially revolutionary, given it's little more than a simple mapping of a name to a URL where the URL can be edited.
But depending on how much paranoia I want to add to the mix, this has as its main function the creation of a master index of people and their interactions/lookups, all under the ownership of Google - whereas previously they didn't have access to that information from facebook or twitter or dodgyfiledump et. al.* and would have to rely on information harvested from ads etc.
Sod it, full paranoia mode. Black helicopter ahoy!
.
* depending on who's bought what and how out of date I am...
> How about a "global namespace"?
Many moons ago, a wise French guard with an outrageous accent once said "we've already got one"...
Less seriously, the question is whether a lookup in an index to find where something is located is really revolutionary, or whether it's an old idea with all-hail-google as the proposer.
My global personal namespace locators start with +44. Well, two of them do, one of them starts with 'where TF has the bstard charger got to'.
Thanks for the DOI link - I wasn't aware of that initiative.
I would suggest that they are also trying to re-invent the URI - the I standing for identifier rather than URL's L meaning locator.
The biggest problem at the moment is blah... blah.. blah.. links go stale.. blah. I was going to write something technical about not paying to upgrade links etc but I rather suspect this initiative will fail because it doesn't include an animated emoji in the link text. <sigh>
Shouldn’t it be possible to have the image flow directly from Facebook to Twitter?
Yes, 'cos those services aren't competing to pwn teh internets at all and just love their users to be able to hop seamlessly from the one to the other.
Presumably the expected implementation date is sometime after Hell freezes over?
It appears there are two points here:
1. Where do I store my information - and I assume I only want to store it once.
2. How do people access it.
1. Where do I store it? Obviously in the cloud. Nothing new there.
2. How do people access it. That's the sticky part. I agree with the above - an email style address is not the answer. It needs to be some unique identifier which, while it may resolve to a URL, is not reliant on a DNS style name for it's identity. The ID could also encompass the permissions - so possibly more than one ID per piece of information (but that's another big can of worms).
I don't think Google have the answer yet - but they are good in just asking the questions.
Alan
"1. Where do I store it? Obviously in the cloud. Nothing new there."
The obvious (to me, anyway) problem with that is that idea of "in the cloud". There isn't one single "the cloud" for it to be in. Instead, there are lots of (competing) different clouds that strongly resemble cloud-shaped silos or silo-shaped clouds or something And ultimately, that's the problem that needs to be solved.
And no, I don't have a solution.
As usual, this is a conceptual idea, which they haven't really thought through.
Let's say you have a web application and it allows you to upload files, and then share them with other users, in the application. Like, you know, a large number of apps at the moment. If the files resided on this system they've invented, all of the application software now has to be re-written, such that when you grant (or deny) access, it writes the permission data (and the files themselves) somewhere outside the application. The application itself then has no idea of the permissions...unless you duplicate that data elsewhere, or use some sort of API to feed the permissions data in from their service...again requiring a rewrite of your app. If the permissions change, you have to update it both in the application and on their system. This does not "cut down" anything, it's making more fecking work.
So, sorry, but that's absolutely fucking useless, to 99% of people.
By the way: If you want a photo to appear on both Facebook and Twitter, just set the permissions in either to make that asset public. So it's, you know, shareable.
Mark my words. This plan will either go the way of wave and just into the sunset, or remove the personally identifying part of the unique address.
I'll show you an example in a different part of IT. Dropbox thought it had cloud file synchronisation tied up, until box introduced Application accounts.
No longer did applications using cloud storage need to be associated with an email account of someone.
Make the address unique, but not associated with a person.
...and the fact that no large group of geniuses has gotten together to write an open-native-across-all-platforms-and-OSes network file system (that would solve all of the issues related to CIFS and NFS), is telling. I know it will never happen, but imagine what could be if one were to be developed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
