IRC log of dig on 2011-09-27
Timestamps are in UTC.
- 00:02:53 [manu`]
- manu` has quit (Ping timeout: 256 seconds)
- 00:17:02 [manu`]
- manu` (~chatzilla@pool-71-171-23-90.nwrknj.east.verizon.net) has joined #dig
- 00:31:17 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 00:37:25 [lkagal]
- lkagal has quit (Quit: lkagal)
- 00:40:28 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 00:44:40 [lkagal]
- lkagal has quit (Client Quit)
- 01:53:40 [rszeno]
- rszeno (~rszeno@79.114.102.185) has joined #dig
- 02:00:42 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 02:17:26 [Pipian_]
- Pipian_ has quit (Quit: Pipian_)
- 03:01:13 [lkagal]
- lkagal has quit (Quit: lkagal)
- 03:06:51 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 03:11:51 [kennyluck]
- kennyluck has quit (Quit: kennyluck)
- 03:40:19 [manu`]
- manu` has quit (Ping timeout: 260 seconds)
- 03:53:15 [manu`]
- manu` (~chatzilla@pool-96-240-178-158.ronkva.east.verizon.net) has joined #dig
- 05:15:48 [lkagal]
- lkagal has quit (Quit: lkagal)
- 06:58:07 [nunnun_away]
- nunnun_away is now known as nunnun
- 07:02:04 [danbri]
- danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) has joined #dig
- 07:32:47 [nunnun]
- nunnun is now known as nunnun_away
- 07:35:43 [nunnun_away]
- nunnun_away is now known as nunnun
- 08:08:30 [tlr_]
- tlr_ (~tlr@195.166.117.133) has joined #dig
- 08:12:55 [nunnun]
- nunnun is now known as nunnun_away
- 08:17:46 [nunnun_away]
- nunnun_away is now known as nunnun
- 08:48:27 [tlr_]
- tlr_ has quit (Quit: tlr_)
- 09:35:20 [nunnun]
- nunnun is now known as nunnun_away
- 11:05:00 [nunnun_away]
- nunnun_away is now known as nunnun
- 11:05:56 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 11:09:07 [kennyluck]
- kennyluck (~kennyluck@119.57.31.100) has joined #dig
- 11:09:32 [RalphS]
- RalphS (Ralph@30-7-118.wireless.csail.mit.edu) has joined #dig
- 11:13:56 [lkagal]
- lkagal has quit (Quit: lkagal)
- 11:28:27 [lkagal]
- lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
- 12:16:07 [nunnun]
- nunnun is now known as nunnun_away
- 12:16:08 [rszeno]
- rszeno has quit (Ping timeout: 256 seconds)
- 12:55:03 [rszeno]
- rszeno (~rszeno@79.114.98.249) has joined #dig
- 13:09:39 [lkagal]
- lkagal has quit (Quit: lkagal)
- 13:19:31 [nunnun_away]
- nunnun_away is now known as nunnun
- 13:19:47 [nunnun]
- nunnun is now known as nunnun_away
- 13:20:50 [tlr_]
- tlr_ (~tlr@195.166.117.133) has joined #dig
- 13:36:38 [tlr_]
- tlr_ has quit (Quit: tlr_)
- 13:42:05 [timbl]
- timbl (~timbl@31-33-115.wireless.csail.mit.edu) has joined #dig
- 14:08:24 [melvster]
- melvster (~melvin@p5797F35A.dip.t-dialin.net) has joined #dig
- 14:24:33 [tlr_]
- tlr_ (~tlr@195.166.117.133) has joined #dig
- 14:26:36 [tlr_]
- tlr_ has quit (Client Quit)
- 14:57:00 [Pipian_]
- Pipian_ (~pipian@31-34-246.wireless.csail.mit.edu) has joined #dig
- 15:10:44 [tlr]
- tlr (~tlr@195.166.117.133) has joined #dig
- 15:12:16 [tlr]
- tlr has quit (Client Quit)
- 15:20:46 [tlr]
- tlr (~tlr@195.166.117.133) has joined #dig
- 16:01:44 [lkagal]
- lkagal (~lkagal@30-7-246.wireless.csail.mit.edu) has joined #dig
- 16:03:05 [tlr]
- tlr has quit (Quit: tlr)
- 16:15:42 [manu`_]
- manu`_ (~chatzilla@pool-74-107-167-56.ronkva.east.verizon.net) has joined #dig
- 16:15:49 [manu`]
- manu` has quit (Ping timeout: 240 seconds)
- 16:15:56 [manu`_]
- manu`_ is now known as manu`
- 16:17:18 [melvster]
- presbrey: hi!
- 16:19:56 [presbrey]
- hi melvster whats up?
- 16:20:51 [melvster]
- just saying hello ... from next week I'll be able to spend all my time on sem web stuff ... i was wondering if you saw that post saying XHR PUT worked with same origin, but not cross origin?
- 16:21:34 [presbrey]
- I think so but I did not follow well, didn't see a link URL or code example?
- 16:22:08 [presbrey]
- is our CORS code bugged?
- 16:22:26 [melvster]
- im not sure it may be firefox
- 16:22:38 [melvster]
- basically there's some code you can use in js to create a file on data.fm
- 16:23:00 [melvster]
- e.g.
- 16:23:01 [melvster]
- xhr = new XMLHttpRequest();
- 16:23:01 [melvster]
- xhr.open('PUT', 'https://melvincarvalho.data.fm/test5', false);
- 16:23:11 [melvster]
- xhr.setRequestHeader('Content-Type', 'text/turtle; charset=UTF-8');
- 16:23:28 [melvster]
- xhr.send('@prefix rdf: <http://www.w3.org/1999/02/22/rdf-syntax-ns#>.\n\n<#a> <#b> <#c>.');
- 16:23:43 [melvster]
- that works in firefox if you're in the same origin
- 16:23:56 [melvster]
- but not on cross origin ... was the gist of it
- 16:24:17 [melvster]
- you can try it in firebug for example
- 16:24:34 [melvster]
- DELETE also works nicely instead of PUT
- 16:24:51 [presbrey]
- firefox bug?
- 16:25:18 [presbrey]
- err. they'll probably say "feature"
- 16:25:41 [melvster]
- quite possibly ... ill investigate further .... but it's got me thinking
- 16:26:01 [melvster]
- the unhosted guys said, you can use oauth instead to get a token
- 16:26:13 [melvster]
- but i was thinking about ACL in general
- 16:26:25 [melvster]
- we have iirc read / write / control / append
- 16:26:38 [nunnun_away]
- nunnun_away is now known as nunnun
- 16:27:17 [melvster]
- but if you look at the common interaction today on the web, before you can do a WRITE, there's normally a confirmation dialogue
- 16:27:35 [melvster]
- e.g. 'are you sure you want to post this to facebook' ... etc.
- 16:28:29 [melvster]
- im wondering the best way to model that user experience (of course it's not such an issue for robots)
- 16:28:55 [melvster]
- it all ties in with the cross origin read / write stuff i think ....
- 16:32:29 [presbrey]
- hmm timbl when did you add http://www.w3.org/ns/auth/acl#Append ?
- 16:33:25 [presbrey]
- oh nvm, acl.n3 Last-Modified: Fri, 18 Jun 2010 21:03:38 GMT
- 16:36:16 [presbrey]
- yall should add mtime to http://www.w3.org/ns/auth/,access
- 16:41:59 [nunnun]
- nunnun is now known as nunnun_away
- 16:42:01 [nunnun_away]
- nunnun_away is now known as nunnun
- 16:56:30 [timbl]
- presbrey, hi -- I have this HTML skin file which you can send instead of RDF to a non-rdf browser
- 16:56:39 [timbl]
- it gives a tabulator-like view of the data, works with # URIs too
- 16:57:03 [timbl]
- like http://www.w3.org/People/Berners-Lee/card#i if you access it with safari say.
- 16:57:18 [timbl]
- Data.fm could do the samething
- 16:58:29 [timbl]
- Yes, append access is for things like dropboxes in intrays.
- 16:59:49 [melvster]
- nice!
- 17:00:06 [nunnun]
- nunnun is now known as nunnun_away
- 17:00:28 [nunnun_away]
- nunnun_away is now known as nunnun
- 17:01:03 [timbl]
- (append access or the skin?)
- 17:01:11 [melvster]
- skin :)
- 17:01:48 [melvster]
- timbl: i was pondering last night ... as well as the read / write and control interactions that we have (common in the unix world) ... i was wondering your thoughts on the concept of "write access with confirmation"
- 17:02:46 [melvster]
- what I mean by this is: write to the following file, but ask for a confirmation first, this is a common pattern with human interaction on the web, e.g. facebook, before an app can post to your wall it pops up something allowing you to confirm or cancel ...
- 17:03:38 [melvster]
- you can model this by putting an app in between the user and data storage area, or "trusted third party" giving you access, or perhaps another property in the ontology
- 17:03:45 [melvster]
- I hope some of that made sense!
- 17:14:51 [melvster]
- hi
- 17:15:03 [melvster]
- not sure how well i phrased the above ....
- 17:15:26 [timbl]
- so wtite with confirmation means confirmation by whom?
- 17:15:45 [melvster]
- i think in this case it would be a human agent
- 17:16:09 [nunnun]
- nunnun is now known as nunnun_away
- 17:16:32 [timbl]
- One way to model this is like with friends on facebook, you put one lin in tosuggest somethig and the it is confirmed by another person writing the link
- 17:16:53 [timbl]
- A append-only dropbox is useful there.
- 17:17:31 [melvster]
- interesting
- 17:17:38 [timbl]
- So the calendar app could write an event into your drob box, linking to a sensitive graph node.
- 17:17:59 [timbl]
- Your software then asks whether you want to confirm the data, and if you do a link is mde from your data to it
- 17:18:03 [melvster]
- so the drop box acts as a kind of notification queue?
- 17:18:10 [timbl]
- yes.
- 17:18:24 [timbl]
- like an inbox
- 17:18:28 [melvster]
- yes that is a nice achitecture
- 17:18:31 [timbl]
- or a input message queue.
- 17:18:49 [timbl]
- The things aren't considered approved until yo have like dto em from storage only you control
- 17:19:52 [melvster]
- so maybe you have a robot sitting between your inbox and your read/write cloud storage?
- 17:20:39 [melvster]
- or you are redirected to your inbox for processing ...
- 17:21:47 [timbl]
- Well, this is all in r/w cloud storage
- 17:21:53 [timbl]
- the dropbix os part o fit.
- 17:22:02 [timbl]
- Yes, you have lots of robots
- 17:22:16 [melvster]
- ok that makes sense
- 17:23:56 [melvster]
- i guess each robot will have a URI webid and public/private key pair
- 17:29:57 [melvster]
- i could even have a bunch of them sitting on my local box on a subdomain ... they can be like my 'butlers' to the web :)
- 17:31:18 [manu-db]
- sounds quite a bit like OAuth, right?
- 17:31:45 [melvster]
- yes similar, but OAuth is trusted third party, right?
- 17:35:51 [melvster]
- so I'm going to have a bunch of robots hosted from my local pc here ... http://robots.melvin.me/ /1 /2 /3 ... given them all WebIDs then allow them to work on my read write clouds
- 17:36:36 [melvster]
- every now and then they'll check things like my message queues and see if anything needs processing
- 17:37:31 [melvster]
- then I can access control them from one big foaf : group
- 18:20:30 [presbrey]
- ps. https://github.com/presbrey/data.fm/
- 18:20:36 [presbrey]
- github fork-ready
- 18:37:33 [melvster]
- great!
- 18:40:36 [manu-db]
- melvster: Sorry - had a meeting - OAuth covers authorizing a third party to do something on your behalf.
- 18:41:07 [manu-db]
- but this could easily be "allow this write to occur." - but it would have to be done with you in the loop.
- 18:41:11 [melvster]
- ah yes ... the unhosted guys are using oauth ... they've also been working on patches for data.fm
- 18:41:38 [manu-db]
- So, if Google wanted to write some data to your WebID - they'd have to get your authorization first via OAuth.
- 18:41:57 [manu-db]
- Then they could add whatever they wanted (based on the access privileges you gave them)
- 18:42:47 [manu-db]
- /or/ you would have to verify each write in-line.
- 18:43:02 [manu-db]
- the benefit of the "semantic inbox" would be not having to be in the loop
- 18:43:25 [manu-db]
- but the down-side is that you have to authorize each data write request - and not many people care about managing that sort of stuff.
- 18:43:39 [manu-db]
- (nor should they have to worry about managing that sort of stuff).
- 18:43:51 [presbrey]
- more likely Google wants to host your profile and you write a seeAlso triple
- 18:43:52 [manu-db]
- managing my inbox is difficult enough - I don't want a semantic inbox that I have to manage as well.
- 18:44:22 [manu-db]
- yes, but that's you writing to Google, not Google writing to your personal data store, right?
- 18:44:26 [presbrey]
- either way
- 18:44:35 [presbrey]
- why let them write to your primary profile graph?
- 18:44:47 [presbrey]
- let them write into another graph that you link to via seeAlso
- 18:44:51 [manu-db]
- why not allow them to write to it?
- 18:45:02 [presbrey]
- I wouldn't want them adding more keys
- 18:45:07 [manu-db]
- (other than the obvious reasons - you don't trust them, they might corrupt data, etc)
- 18:45:16 [manu-db]
- yes, but that has to do with ACL
- 18:45:28 [manu-db]
- don't allow them to write keys - that's another privilege.
- 18:45:38 [manu-db]
- but writing your Google+ stream as semantic data may be okay?
- 18:46:01 [presbrey]
- sorry not just data keys, specifically webid / pki public keys
- 18:46:18 [manu-db]
- plus, your semantic data store would have multiple graphs, wouldn't it? perhaps one per URL... so, you could tell Google - I want you to do all writes here: http://data.fm/presbrey/gplus ?
- 18:46:47 [presbrey]
- sure that sounds fine
- 18:46:49 [manu-db]
- and then you could link to that URL from your main profile?
- 18:46:59 [presbrey]
- so why would I need to 'authorize each request' / down-side?
- 18:47:14 [manu-db]
- and for that use case - OAuth (or something like it - WebID) would work quite well.
- 18:47:37 [presbrey]
- I have lots of (sub) profile graphs
- 18:47:43 [manu-db]
- presbrey: 'authorize each request' - are we talking about the semantic inbox use case?
- 18:49:00 [presbrey]
- in any case I think we can agree the ACL onto needs some extension
- 18:49:29 [presbrey]
- w/ OAuth directives, password (Basic/Digest) eg. htaccess, etc.
- 18:49:48 [melvster]
- presbrey: did you see the sec ontology?
- 18:49:57 [presbrey]
- FB calls it 'offline access' when you don't want to authorize each request
- 18:50:10 [presbrey]
- no melvin, link?
- 18:50:46 [manu-db]
- This is the one we're working on - http://payswarm.com/vocabs/security
- 18:51:08 [presbrey]
- hmm interesting
- 18:51:32 [manu-db]
- It's used here: http://payswarm.com/specs/source/web-api/
- 18:51:44 [manu-db]
- Look at Section 4: Communication
- 18:52:20 [manu-db]
- Section 4.7 should be the last section of Section 4.
- 18:52:41 [manu-db]
- The sec ontology is used to encrypt/decrypt messages in the clear (over HTTP)
- 18:52:55 [manu-db]
- (and to do digital signatures on messages - with resistance to replay attacks)
- 18:53:49 [manu-db]
- We also define a mechanism that allows public keys to be registered - but specific to PaySwarm - it could be generalized, though.
- 18:54:09 [melvster]
- that's the one ..
- 18:54:21 [melvster]
- i think 'sec' is the prefix in prefix.cc
- 18:54:33 [rszeno]
- rszeno has quit (Ping timeout: 258 seconds)
- 18:55:09 [presbrey]
- prefix.cc points to purl points to 404
- 18:55:36 [manu-db]
- yes, the purl hasn't been approved yet - working on it!
- 18:57:53 [presbrey]
- hmm security like admin are probably hard keywords to reserve
- 18:57:57 [rszeno]
- rszeno (~rszeno@79.114.105.153) has joined #dig
- 19:05:49 [melvster]
- github fork looks great ... i think ill try and run a local copy too
- 19:11:03 [presbrey]
- you might need to fix php include_path
- 19:11:22 [presbrey]
- let me know what other trouble you run into
- 19:12:04 [presbrey]
- timbl also wants to run his own local fork
- 19:12:59 [melvster]
- will do ...
- 19:22:45 [presbrey]
- thanks :)
- 19:29:00 [timbl]
- $ git checkout https://github.com/presbrey/data.fm.git
- 19:29:00 [timbl]
- fatal: Not a git repository (or any of the parent directories): .git
- 19:29:23 [melvster]
- try git clone
- 19:29:36 [melvster]
- git clone https://github.com/presbrey/data.fm.git
- 19:30:28 [timbl]
- works tx
- 20:01:02 [lkagal]
- lkagal has quit (Quit: lkagal)
- 20:05:44 [lkagal]
- lkagal (~lkagal@30-7-246.wireless.csail.mit.edu) has joined #dig
- 20:23:33 [RalphS]
- RalphS has quit ()
- 21:28:16 [lkagal]
- lkagal has quit (Ping timeout: 248 seconds)
- 22:00:51 [danbri]
- danbri has quit (Remote host closed the connection)
- 22:15:47 [timbl]
- http://www.w3.org/wiki/WebAccessControl
- 22:22:21 [presbrey]
- presbrey has quit (Ping timeout: 244 seconds)
- 22:40:44 [Pipian_]
- Pipian_ has quit (Quit: Pipian_)
- 23:04:39 [rszeno]
- rszeno has quit (Quit: Leaving.)
- 23:08:18 [rszeno]
- rszeno (~rszeno@79.114.93.230) has joined #dig
- 23:46:53 [timbl]
- timbl has quit (Quit: timbl)