tag:blogger.com,1999:blog-759829936301057674.post27097803057397544..comments2023-10-17T15:09:44.748+01:00Comments on About Tag: Permissions Worth Getting Excited Aboutnjrhttp://www.blogger.com/profile/08980758986023344486noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-759829936301057674.post-34192234992851258182009-09-04T14:15:04.818+01:002009-09-04T14:15:04.818+01:00Got it,
Knew I was being slow.
Makes sense.
Nic...Got it,<br /><br />Knew I was being slow.<br /><br />Makes sense.<br /><br />Nicknjrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-22800848128582346342009-09-04T14:07:23.013+01:002009-09-04T14:07:23.013+01:00Our suggestions are complimentary.
When you say &...Our suggestions are complimentary.<br /><br />When you say "App requests permission to do certain things to certain of the user's namespaces and/or (abstract) tags" - I'm just suggesting a mechanism by which the app can identify the FluidDB user in question, without that user needing to remember their FDB login credentials.<br /><br />As per your recommendations, FluidDB needs to give (for example) write permission to /users/app on certain of /users/bob 's tags. And the app itself will write tags such as /bob/likes etc. <br /><br />I'm just suggesting a way of uniquely identifying 'bob' in both contexts.David Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-61244511527183539722009-09-04T13:27:07.342+01:002009-09-04T13:27:07.342+01:00I'm probably being slow, David, but I don'...I'm probably being slow, David, but I don't quite follow.<br /><br />I'm certainly with you in spirit: a key idea is that lots of different apps/services/tag managers can all potentially be authorized to manipulate various of the user's namespaces and tags. I was suggesting a possible short-term way to achieve that.<br /><br />I don't entirely get either what you mean by "The 'david' FDB object" or by "returning a FluidDB user ID".<br /><br />But I think the key point is, whatever the detail, the nature of the transaction is<br /><br />1. App requests permission to do certain things to certain of the user's namespaces and/or (abstract) tags.<br />2. The user is rediected to the FluidDB website and either agrees or declines<br />3. If the user authorized it, the app can manipulate those tags or namespaces until such time as the user revokes that permission.<br /><br />The app uses its own credentials and the user never need share his/her password with anyone.<br /><br />I think is probably what you're describing too, but I couldn't quite glean that from your words.<br /><br />Cheers<br /><br />Nick<br />]njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-55363556280335513402009-09-04T12:27:58.883+01:002009-09-04T12:27:58.883+01:00That's all great stuff Nick.
I was actually ...That's all great stuff Nick. <br /><br />I was actually thinking one level up, i.e. a generic library for returning a FluidDB user id on the basis of a number of external authorization services.<br /><br />The FFB architecture is perfect for allowing multiple such services to be attached to the same user object. <br /><br />For example, the 'david' FDB object:<br /><br />/auth/twitter.com/hymanroth<br />/auth/facebook.com/dsemeria<br />/auth/google.com/dsemeria<br />/auth/disqus.com/hymanroth<br />etc...<br /><br />This would lead to a users (multiple) external identities being stored in the same place, and would hence allow FDB users to access the system without ever having to know (or remember) their FDB credentials.<br /><br />It's also a great example of FDB's central data accumulation thesis being put to good use.David Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-40151371433215310262009-09-03T18:57:05.178+01:002009-09-03T18:57:05.178+01:00I think that's right, David. Of course, the ...I think that's right, David. Of course, the key thing with this authorization would be that it wouldn't be (normally) a blanket request to be able to do anything, but rather to do particular things with particular tags. So conceptually, it's a web page that an app can direct you to that sends information such as<br /><br />iLike is requesting permission to read and write the bob/likes tag<br /><br />The user allows this or doesn't.<br /><br />Obviously this isn't a long-term solution, but I have reflected on the fact that an interim measure for people with FDB (my command line utility) is that if/when I add commands for changing tag permissions, an app could simply print the set of FDB commands that are needed to enable the access and people could grant it themselves. (Yes, I know, this is not even an approximation to a long-term solution; but for the current stage with developers etc...) So in this case, it might simply be (bearing in mind that I haven't actually defined these commands yet) something along the lines of<br /><br />fdb chmod -u iLike +w +r /njr/likes<br /><br />(reading roughly "Change the permissions mode on the njr/likes tag to give the user iLike read and write permission)".<br /><br />But as you are about to say, in the medium term, there will probably be users who prefer using a web app to installing fdb.py and using the command line! Obviously, it might be desirable for such a web app to be hosted at fluidinfo.com, perhaps the only place we should really be encouraging users to type passwords, preferably using https.<br /><br />Nicknjrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-7250606374933919942009-09-03T18:42:03.110+01:002009-09-03T18:42:03.110+01:00..this suggests to me that someone (not me!) shoul.....this suggests to me that someone (not me!) should start thinking about generic authentication library, similar to the ones they have on commenting systems, where you can identify yourself to the system via a variety of existing pseudonyms (twitter id, FB id, etc).<br /><br />It looks like it would be a key component, since most users will access the DB via a 3rd party application.<br /><br />Given time constraints, the most I can offer would be a line-for-line port to PhP :-)David Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-57451243150075903952009-09-03T11:25:52.959+01:002009-09-03T11:25:52.959+01:00Totally, but it implies users of iLike must first ...Totally, but it implies users of iLike must first create a FluidDB identity if they don't already have one. But I agree the benefits of this approach outweigh the cost.David Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-60701607833606019032009-09-03T10:51:47.614+01:002009-09-03T10:51:47.614+01:00David
I thought that was probably what you meant....David<br /><br />I thought that was probably what you meant...<br /><br />There is no official answer, but my strong preference and recommendation is a mixture. I think applications should log in with their own credentials, but that users should grant those applications the necessary permissions on whatever subset of their tags and namespaces they want them to use.<br /><br />So, in most cases, I would have the app iLike log in with its credentials and act as a tag manager for /bob/likes, with Bob's explicit permission and without ever needing his credentials. It could, of course, stick all its tags in the subspace /bob/iLike/likes, but that seems to me to go against the whole cross-application spirit that we're trying to foster.<br /><br />Does that make sense?<br /><br />Nicknjrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-9414139588783556462009-09-03T10:39:54.767+01:002009-09-03T10:39:54.767+01:00Sorry Nick, I meant Fluid DB.
I was just asking w...Sorry Nick, I meant Fluid DB.<br /><br />I was just asking whether the preferred route is for people to log into applications using their FluidDB credentials, or whether each application would have its own user management system.<br /><br />In other words, it's the difference between /app/bob/likes and /bob/app/likes.<br /><br />CheersDavid Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-75580633014658283432009-09-03T08:18:13.667+01:002009-09-03T08:18:13.667+01:00Hi David
Not sure whether by FDB you mean FluidDB...Hi David<br /><br />Not sure whether by FDB you mean FluidDB or my FDB (fdb.py) library, but perhaps it makes no difference.<br /><br />I do plan probably a couple more posts on permissions, one going into more detail on namespaces and the actual controls and one talking about fdb.py's approach to it, both through the library and the command line.<br /><br />Of course, I have to write those bits of the library and command line interface first. The two sort-of go hand in hand.<br /><br />Briefly, though, as far as I know there is absolutely no difference at all between an application and a user as far as FluidDB is concerned. Indeed, even the fluiddb user/application is an entirely ordinary user as far as the system is concerned. There's just a fluiddb user, used by the fluiddb application.<br /><br />As for namespaces---well they probably do deserve their own post, but the gist of the idea is that if tags are a bit like files (and tag values their contents) then namespaces are a lot like directories (or "folders", in newspeak). And just like directories, namespaces have their own permissions and policies, allowing you to control who can see them, read them, create new items in them and so forth.<br /><br />Hope that helps...briefly. There'll be more (or, "I'll be back", as the Governator might say)njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-3463588577500686842009-09-02T20:57:45.004+01:002009-09-02T20:57:45.004+01:00Hi Nick, I read the FDB documentation in my usual ...Hi Nick, I read the FDB documentation in my usual half-arsed way. Perhaps it would be useful to write a post detailing the difference between users (applications - i.e. api access) and users (individuals).<br /><br />It's not too clear to me how all this relates to namespaces (application or individual?)and by implication the underlying tag permissions. <br /><br />Cheers<br /><br />D.David Semeriahttps://www.blogger.com/profile/15600017373977829076noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-81557260067151352182009-09-02T18:49:33.617+01:002009-09-02T18:49:33.617+01:00Holger
You're obviously right that faithfully...Holger<br /><br />You're obviously right that faithfully moving data from any system with finer-grained permissions to one with coarser control will always be a challenge. We could have gone further and given users the abilty to set policies and permissions on individual items of data, rather than working at the level of a set of tags sharing a name. One of the reasons we didn't was we were quite interested in the idea of tag managers---applications that would look after one or more of a user's abstract tags for them. Bearing in mind that you can also grant permissions and poicies on namespaces, allowing an application to create tags in a subnamespace, for example, this is quite powerful.<br /><br />While I can't think of too many applications people might want to pull data from that have more granular control than FluidDB, I'm sure they exist and that at some point someone (probably me) will curse FluidDB for not being even more flexible.<br /><br />So---point taken. Let's see how it goes.<br /><br />Nicknjrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-88829978266392708562009-09-02T15:14:54.360+01:002009-09-02T15:14:54.360+01:00Correct about the thing that is private (bookmark ...Correct about the thing that is private (bookmark vs tag).<br />I agree with your first comment that one should just have delicious_tags and private_delicious_tags.<br /><br />But what if we need to map a system where the privacy dimension has more than two state (private and public)? We'll get into a situation where we have an exponential amount of tags (public_foo, private_foo, private_except_bob_foo, private_except_alice_foo, private_except_alice_andbob_foo, ...).Holger Dürerhttps://www.blogger.com/profile/00555282306926644834noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-81342502408252837732009-09-02T07:57:32.272+01:002009-09-02T07:57:32.272+01:00Holger
Thinking about it slightly more, I have a ...Holger<br /><br />Thinking about it slightly more, I have a second comment on your perceptive comment. It's that in delicious, it's not tags at all that have permissions, but bookmarks. I can't choose to let the world see that I've tagged http://fluidinfo.com/fluiddb with "awesome" but not that I've tagged it with "by-my-friend-terry". I choose either to let people see that I've bookmarked http://fluidinfo.com/fluiddb, or not, and if it's shared, they can see my tags.<br /><br />So the model really is very different.<br /><br />Thanks again.<br /><br />Nicknjrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-85104333803830533612009-09-02T07:41:28.382+01:002009-09-02T07:41:28.382+01:00Holger
You're right, the permissions are at t...Holger<br /><br />You're right, the permissions are at the level of what I call the "abstract tag", which is what you mean when you say the tag as opposed to the value.<br /><br />In terms of the delicious importer, although it does what I think is the "natural" thing (or at least the most direct thing), there are probably better ways of allowing FluidDB to exploit the information. In particular, there's a case for having a single tag, perhaps called "tags" or "delicious tags" or whatever and having this have a value that's a set of strings. That would solve the problem because you could just have a private-tags tag, or whatever.<br /><br />But your point is fundamentally correct.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-26445340375709662422009-09-02T07:34:42.159+01:002009-09-02T07:34:42.159+01:00But, as I understand it, permissions are granted p...But, as I understand it, permissions are granted per tag, not per value. This implies that in some cases (take e.g. the delicious importer) one has to have a duplicate set of tags (e.g. delicious/books and delicious/private/books) where each tag in delicious has two tags in FluidDb which to you mean the exactly the same but are needed to control privacy which in delicious is orthogonal to tagging.Holger Dürerhttps://www.blogger.com/profile/00555282306926644834noreply@blogger.com