01:21:50 <melvster> melvster has quit (Ping timeout: 240 seconds)
02:45:55 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-226-107.w86-198.abo.wanadoo.fr) has joined #dig
02:47:23 <bblfish> bblfish has quit (Remote host closed the connection)
05:28:33 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-226-107.w86-198.abo.wanadoo.fr) has joined #dig
06:05:25 <tyteen4a03> tyteen4a03 has quit (Ping timeout: 245 seconds)
06:18:21 <bblfish> bblfish has quit (Ping timeout: 245 seconds)
06:33:48 <bblfish> bblfish (~bblfish@AAubervilliers-652-1-89-229.w83-114.abo.wanadoo.fr) has joined #dig
06:41:41 <tyteen4a03> tyteen4a03 (tyteen4a03@2001:470:e2e4::) has joined #dig
07:04:42 <bblfish> bblfish has quit (Remote host closed the connection)
07:14:50 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-226-107.w86-198.abo.wanadoo.fr) has joined #dig
07:16:41 <bblfish> bblfish has quit (Remote host closed the connection)
07:28:44 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-226-107.w86-198.abo.wanadoo.fr) has joined #dig
07:40:40 <deiu> deiu (~andrei@157.159.103.113) has joined #dig
07:40:40 <deiu> deiu has quit (Changing host)
07:40:40 <deiu> deiu (~andrei@unaffiliated/deiu) has joined #dig
07:43:34 <bblfish> bblfish has quit (Remote host closed the connection)
08:40:47 <jmvanel> jmvanel (~jmvanel@199.0.88.79.rev.sfr.net) has joined #dig
09:12:13 <Yudai_> Yudai_ has quit (*.net *.split)
09:12:16 <sandro> sandro has quit (*.net *.split)
09:20:15 <sandro> sandro (~sandro@ssh.w3.org) has joined #dig
09:20:15 <Yudai_> Yudai_ (~Yudai@nttkyo218001.tkyo.nt.ngn2.ppp.infoweb.ne.jp) has joined #dig
09:31:26 <timbl> timbl (~timbl@host86-146-148-68.range86-146.btcentralplus.com) has joined #dig
09:45:36 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
09:45:52 <melvster> melvster (~melvster@89.176.108.70) has joined #dig
10:20:20 <bblfish> bblfish has quit (Remote host closed the connection)
10:20:53 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
10:25:54 <bblfish> bblfish has quit (Ping timeout: 276 seconds)
11:00:14 <deiu> deiu has quit (Read error: Connection reset by peer)
11:00:42 <deiu> deiu (~andrei@unaffiliated/deiu) has joined #dig
11:24:18 <RalphS> RalphS (rswick@w3cvpn1.w3.org) has joined #dig
11:48:44 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
12:06:36 <bblfish> bblfish has quit (Remote host closed the connection)
12:08:56 <bblfish_> bblfish_ (~bblfish@90.24.245.239) has joined #dig
12:25:53 <bblfish_> bblfish_ has quit (Remote host closed the connection)
12:29:51 <timbl> presbrey?
12:30:20 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
12:30:38 <timbl> Seems that when spawning a new tracker, I'm getting 200 back from the PUT but no actual data stoted
12:32:02 <timbl> e.g. http://timbl.data.fm/test/issuetracker.w3.org/1378748362742/track should have bunch of triples in
12:33:31 <timbl> This happens whether using the code for making a new tracker, or just curl -v --upload-file foo2.n3 -HContent-type:text/turtle http://timbl.data.fm/test/issuetracker.w3.org/1378748362742/track
12:42:36 <deiu> timbl, about your last question regarding rww.io and data.fm, they should be merged (maybe replace data.fm with rww.io since it brings lots of new features)
12:44:40 <deiu> rww.io should support the old ACL convention (.meta in the / dir), but I need to check with presbrey and test it
12:49:59 <timbl> By merge, that would leave the source trees the same.   Just get the best of both'
12:50:23 <timbl> When it comes to the .meta .acl etc
12:50:50 <timbl> the main thing is that there is a common protocol -- and a common client-ide library -- that works with either way.
12:51:41 <timbl> So it shouldn't matter what the filename is, but it should matter that  client find s it in a standard way
12:56:28 <scor> scor (scor@drupal.org/user/52142/view) has joined #dig
12:58:20 <bblfish> bblfish has quit (Ping timeout: 245 seconds)
12:58:47 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
13:01:50 <deiu> timbl, wouldn't it be useful to have a CG/WG to discuss Web ACL stuff?
13:02:02 <timbl> (If I try it with rww.io I get a  403)
13:02:32 <deiu> the goal is to standardize WebACL discovery and management
13:02:35 <timbl> DO you think the Web ACL stuff should be in a separate list, nonpublic-rww ?
13:02:50 <deiu> I think it's part of the RWW CG now, right?
13:04:37 <deiu> are you trying to upload foo2.n3 to rww.io?
13:05:19 <timbl> yes 
13:05:34 <timbl> just s/data.fm/rww.io/ above
13:06:28 <timbl> How can I set that up for public access -- how can I get at my ffox cert and do webid with curl?
13:06:57 <deiu> you can export the cert as pem
13:07:29 <deiu> then use curl --cert or curl -E
13:09:30 <deiu> BTW, you need to set the acl for /test before writing to it as a public user
13:10:09 <deiu> open the UI and tick the Write and Default for new checkboxes 
13:10:28 <deiu> might as well give it Read too
13:11:08 <deiu> hmm or Append instead of Write (can PUT new resources with it)
13:12:10 <timbl> Somethimng which starts -----BEGIN CERTIFICATE-----  is a .pem ?
13:12:18 <deiu> yes
13:13:44 <timbl> so curl -v -E timbl.pem   
13:13:49 <deiu> that should work
13:14:03 <timbl> I still get 403 .. so if I make an ACL on /test/ that will be enough?
13:14:25 <deiu> did you export the cert with a password?
13:14:37 <deiu> in that case: curl -v -E timbl.pem:password
13:15:01 <deiu> or set some default ACL rules for /test/
13:15:40 <deiu> oh, you're using a http:// url
13:15:49 <deiu> you might want to use https:// to trigger WebID auth
13:16:43 <timbl> ooops yes.
13:16:47 <timbl> Ok now I get  unable to set private key file: 'timbl.pem' type PEM
13:18:23 <deiu> did you convert the cert from .p12 to .pem yourself?
13:18:50 <timbl> That is just what you get from the Firefox export button
13:18:51 <deiu> I think FF exports a password protected .p12 by default
13:18:55 <timbl> I din't change it
13:20:03 <deiu> I'm not sure how it behaves on OS X
13:22:56 <timbl> do the thing starting -----BEGIN CERTIFICATE--- might be a p12 not a pem ?
13:24:28 <deiu> I exported a cert using FF and it doesn't have that line (BEGIN CERT..)
13:24:58 <deiu> can you use check if this command works? openssl pkcs12 -in file.p12 -out file.pem
13:25:08 <deiu> replace file.p12 with your cert
13:26:23 <timbl> No, not happy
13:26:24 <timbl> 140735183428028:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319:
13:26:25 <timbl> 140735183428028:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=PKCS12
13:26:51 <timbl> expecting a raw ASN/1 file maybe
13:27:10 <cheater__> cheater__ (~cheater@p5498A868.dip0.t-ipconnect.de) has joined #dig
13:27:44 <deiu> try: openssl x509 -text -in timbl.pem
13:27:52 <deiu> does it print the cert correctly?
13:28:35 <timbl> Yes
13:28:43 <deiu> then it's definitely a pem
13:29:14 <timbl> (includeing URI:https://webid.mit.edu/timbl#)
13:29:28 <deiu> did you set a password when you exported it?
13:29:55 <timbl> No
13:30:20 <timbl> curl would shave prompted I think 
13:30:41 <deiu> I think you might have exported only the public key
13:31:54 <deiu> I find it strange that FF didn't ask for a password, or that it exported by default as PEM 
13:33:33 <timbl> Ah I'd missed the export format option opn FFox export button
13:33:52 <timbl> the default is "X509 cert (PEM)"
13:34:18 <timbl> There is another option X509 cert (PEM) (with chain)"
13:36:16 <timbl> yes the dump of the cert does not have private key info
13:38:06 <deiu> does it work now?
13:39:29 <timbl> I haven't found anything to change.   exporting wit the chain gives the same file
13:40:27 <deiu> what FF version are you using?
13:41:37 <timbl> 23.0.1
13:41:48 <deiu> I have the same version
13:42:24 <deiu> I'm doing Preferences -> Advanced -> Certificates -> View Certificates -> Backup...
13:43:47 <timbl> I was doing View button to get to one cert, then "detail" tab the "expert" button
13:43:52 <timbl> export
13:44:06 <deiu> ah
13:44:10 <deiu> use the Backup... button
13:44:35 <deiu> export will only save the public key
13:44:45 <timbl> That will include al 3 certs and male a p12
13:45:20 <deiu> then you can convert the p12 to pem using: openssl pkcs12 -in file.p12 -out file.pem
13:47:05 <timbl> ok
13:48:43 <timbl> I see .. I though it would backup all 3 but it only does the selected one
13:49:53 <deiu> I think you have a Backup All for that :-)
13:50:03 <timbl> Nice.  * We are completely uploaded and fine
13:50:51 <timbl> https://webid.mit.edu/timbl#
13:51:15 <timbl> from the "User:"  field
13:51:30 <deiu> so it works
13:51:39 <timbl> Is that field a webid standard as it were … can the tabulator client code look for it?
13:51:46 <timbl> Yes, it works
13:52:07 <deiu> it's not a standard but I would REALLY want for it to be 
13:52:34 <deiu> otherwise I don't know how a web app can tell if the user is authenticated or not
13:53:08 <deiu> and User: should be protocol-independent 
13:53:20 <timbl> Well, if your an program the browser, the bit is easy as yo know which cert you are wielding …. and of course a user can have different certs on different stores.
13:53:46 <deiu> you can't access the cert info in all browsers 
13:54:24 <timbl> So we have to be careful of jumping through too many hoops to do things you could do easily programming the cb=broswre, and ten eth browser manufacturers saying that the protocol is unncesessailty complicated
13:54:27 <timbl> :-)
13:55:07 <bblfish> bblfish has quit (Remote host closed the connection)
13:56:18 <deiu> but you still need a way to get feedback from the server regarding which identity is currently "logged in"
13:56:27 <timbl> Yes.
13:56:54 <timbl> But the client in principle knows.  It is just the browser knows, not the webapp
13:57:00 <timbl> or the extension.
13:57:48 <deiu> what if the authentication failed? the browser still knows it used the cert for https://webid.mit.edu/timbl#, but it doesn't mean the server has logged the user in
13:58:27 <deiu> the cert is selected in the browser, but the user has failed to login on the server
13:58:50 <timbl> Well, I think the "User:" is useful anyway.
13:59:29 <deiu> it's a hack
14:00:14 <timbl> why?
14:01:35 <deiu> it's not a standardized header
14:01:35 <bblfish> bblfish (~bblfish@90.24.245.239) has joined #dig
14:01:36 <timbl> In the webid spec it can be.
14:02:17 <timbl> ANy architectural reasons its a hack?
14:02:26 <deiu> not really
14:02:44 <deiu> I suppose we can mention it in the WebID-TLS spec
14:03:16 <deiu> I find it really useful for web apps
14:03:54 <timbl> yes
14:04:21 <timbl> the tabulator has  'me' preference which it uses but the user has to sit themsleves
14:04:47 <timbl> I could, anytime a "User" URI is seen, change that.
14:06:16 <deiu> would it be more useful to have a Link rel=identity header?
14:06:45 <timbl> I think the link rel=  express relationships between the document and other things.
14:06:54 <timbl> The currently logged in user is to that
14:07:03 <timbl> is not that.
14:07:08 <deiu> true
14:07:53 <timbl> (entity headers and protocol headers or something)
14:15:22 <deiu> speaking of link rel, rww.io HTTP responses contain a link=acl for the .acl file and a link=meta for the .meta file (if the resource is not an RDF document)
14:35:50 <tyteen4a03> tyteen4a03 has quit (Ping timeout: 245 seconds)
14:46:15 <betehess> betehess has quit (Ping timeout: 245 seconds)
14:47:23 <tyteen4a03> tyteen4a03 (tyteen4a03@2001:470:e2e4::) has joined #dig
14:48:04 <betehess> betehess (~betehess@2001:470:8b2d:804:4451:91a6:5716:e8cc) has joined #dig
14:49:10 <timbl> is there any client code for changing ACLs ?
14:51:39 <timbl> deiu?
14:52:09 <deiu> no, the web app should handle that
14:52:16 <timbl> I have made a new tracker now using the tracker ane
14:52:20 <timbl> pane
14:52:25 <timbl> at http://timbl.rww.io/test/issuetracker.w3.org/1378824620728/track#TabTracker
14:52:43 <timbl> but that file gets returned with a syntax error
14:53:43 <timbl> Extra dots
14:54:02 <timbl> <#Bug>
14:54:03 <timbl>     a <http://www.w3.org/2000/01/rdf-schema#Class> ;
14:54:04 <timbl>     <http://www.w3.org/2000/01/rdf-schema#label> "bug" ;
14:54:05 <timbl>     <http://www.w3.org/2000/01/rdf-schema#subClassOf> <#TabIssueCategory> ;
14:54:06 <timbl>     <http://www.w3.org/ns/ui#backgroundColor> "#fffed0" ;
14:54:07 <timbl>     <http://www.w3.org/ns/ui#sortOrder> 70. .
14:54:21 <timbl> An extra trailing dot
14:54:30 <timbl> Which serializer are you using?
14:54:53 <timbl> It isn't generaing prefixes 
14:55:58 <deiu> I'm using rdflib
14:56:12 <deiu> that extra dot is weird
14:56:18 <deiu> it's the first time I see it
14:56:53 <deiu> it seems to appear only after an integer value
14:56:58 <timbl> Oh… I think it may be decimal
14:57:07 <timbl> missingt trailing 0
14:57:16 <deiu> yes
14:57:21 <timbl> maybe syntax ambiguity
15:08:20 <betehess> betehess has quit (Ping timeout: 245 seconds)
15:22:48 <betehess> betehess (~betehess@31-35-251.wireless.csail.mit.edu) has joined #dig
15:36:17 <deiu> deiu has quit (Quit: Leaving)
15:59:02 <melvster> timbl deiu: User: is on it's way to becoming a standard ... I've done some consensus gathering with mnot, roy, nathan, kingsley, manu, the rww group and the openid foundation 
15:59:18 <melvster> people were asking for use cases, so I'll write some up
15:59:42 <melvster> the feedback was *not* to reuse the "From: " header as that is for email only
16:00:32 <melvster> unofficially I think it's OK to use, there were suggestions of calling it UserID too, but I think User is just about winning the naming, and it's already in use in data.fm implemented by presbrey
16:00:58 <melvster> I plan to make a wiki page, we have text already, then try and submit it to the IETF registry for feedback
16:01:20 <timbl> What's the best approximation of a webs spec just now?
16:01:42 <melvster> "webs spec" ?
16:02:13 <timbl> webid spec
16:02:15 <deiu> deiu (~andrei@2a01:e35:8b67:4160:2d92:4f6a:612a:a1c1) has joined #dig
16:02:15 <deiu> deiu has quit (Changing host)
16:02:15 <deiu> deiu (~andrei@unaffiliated/deiu) has joined #dig
16:02:19 <timbl> stupid autocorrect
16:03:08 <melvster> timbl:  https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
16:03:38 <melvster> henry wants to publish it next week to it's home at: http://www.w3.org/2005/Incubator/webid/spec/
16:03:42 <melvster> cc bblfish
16:05:43 <timbl> Should User: not be aded as a should to WebID-TLS?
16:05:56 <timbl> or WebID?
16:07:31 <cheater__> cheater__ has quit (Ping timeout: 245 seconds)
16:07:50 <melvster> timbl: in WebID-TLS you get the user from the SubjectAlternativeName ... adding User sounds to me like a good idea, but not sure what the group's opinion on that would be ... 
16:08:45 <melvster> in fact the subject alternative name can contain a list of multiple user URIs
16:08:49 <deiu> timbl, I'll try to put together and propose a paragraph about User: 
16:09:06 <melvster> deiu: I'd be happy to work with you on that ... I already have text for it
16:09:13 <deiu> melvster, I think timbl is referring to the User: header 
16:09:16 <melvster> yes
16:09:26 <deiu> brb
16:10:20 <melvster> DIGlogger, pointer
16:10:20 <melvster> See http://dig.csail.mit.edu/irc/dig/2013-09-10#T16-10-20
16:12:30 <scor> scor has quit (Ping timeout: 245 seconds)
16:14:51 <timbl> Or should it be added to WebID so that the User: field is given whatever the auth method used?
16:15:38 <timbl> Yes I'm talking about a User: HTTP header which I notice I get from rww.io
16:15:43 <timbl> and I like (!)
16:16:33 <scor> scor (scor@nat/acquia/x-epgddxragswxqrhj) has joined #dig
16:16:33 <scor> scor has quit (Changing host)
16:16:33 <scor> scor (scor@drupal.org/user/52142/view) has joined #dig
16:19:00 <deiu> IMO, the User: header should not be part of the WebID spec
16:19:16 <deiu> it should be protocol-independent 
16:19:45 <deiu> there should be a "RWW" spec about these things
16:19:59 <melvster> timbl: User is also useful without auth, I could personalize a page for you, auto filling in many fields without you having to type things on a mobile device, I could also add your name and avatar, and find information from your preferences ... with auth it of course can act as a username
16:20:54 <melvster> and also when you try and *change* something, you need auth or when you access *protected* information
16:21:37 <deiu> melvster, I don't understand
16:22:15 <deiu> personalize a page when you pretend to be someone else?
16:22:45 <melvster> deiu: im only talking about leveraging public information from your profile here
16:23:25 <deiu> User: is returned by the server, not sent by the agent
16:23:37 <melvster> oic
16:24:10 <melvster> hmmmmm
16:24:15 <deiu> it's the server's way of indicating that your request was performed based on that particular identity (which is set in the User header)
16:24:37 <melvster> cant the request send user too?
16:24:45 <deiu> why? 
16:25:01 <deiu> isn't that what authentication does?
16:25:08 <melvster> no!
16:25:17 <melvster> authentication and identification are different things
16:26:04 <deiu> as a server, I have no incentive to personalize (= spend time/resources) a page if I'm not sure I'm doing it for the right person
16:26:31 <deiu> besides, identification without proof is wrong
16:26:47 <deiu> in your use-case at least
16:28:35 <melvster> deiu: it's how communication works in every field, you identify, and only authenticate on demand ... imagine that it was impossible to write someone a letter without proving your identity?
16:28:50 <melvster> or phoning someone up
16:29:11 <melvster> identity and authn are modular concepts
16:31:30 <melvster> deiu: to put it another way, why would anyone want to identify themselves as the *wrong* person?
16:31:47 <deiu> melvster, in your example, you are basically saying that you want the server to display a page and personalize it as if you were timbl 
16:32:28 <melvster> deiu: i didnt say I *want* that ... I said it's a possible use case for the server to use public information associated with a URI, e.g. to auto fill forms
16:32:46 <deiu> like credit card information forms? :-)
16:33:05 <deiu> or full name / address info?
16:33:14 <melvster> deiu: do you keep your credit card details public? ;)
16:33:28 <deiu> no, but the server may save them
16:33:41 <deiu> anyway
16:33:46 <timbl> There are two things
16:33:52 <deiu> I think your use-case is not complete
16:34:07 <deiu> there's information something missing
16:34:35 <deiu> besides, browsers already do autocomplete
16:34:58 <timbl> One is the user id the user has authenticated with tho the server through the client.  The other is the person the clinet understands the users to be, which affects certain data, like stuff about people, where the display will be user-related -- like "You are friends with x".
16:35:47 <melvster> timbl: right, that's used in the social and microblogging panes
16:36:51 <deiu> who sends the second one?
16:40:05 <timbl> The second one is set by the user with the "login in" code  where it prompts for  awe did if you don't have a browsing id 
16:40:14 <timbl> It isn't sent over the net
16:40:22 <timbl> it is local to the client and the user
16:41:04 <timbl> The user agent needs to know whop the user is because it has to start with a lot of user preferences  
16:41:19 <timbl> including which workspaces a user has available, fav language, etc etc
16:41:56 <timbl> Baically like a unit home directory allow you to look up   ~/.xxx rc and ~/.xxx.config etc
16:42:45 <deiu> so the second one is bound to the application
16:42:48 <timbl> In this experimental workspace ontology here is a pointer from th user's public ID to the private preferences file.
16:43:21 <deiu> in other words, it's part of the local preferences
16:43:30 <melvster> timbl: can preferences be public too?
16:43:40 <timbl> http://www.w3.org/ns/pim/space#preferencesFile
16:43:47 <timbl> It could be public
16:43:55 <timbl> but I wouldn't want mine to be
16:44:02 <timbl> as it points to private worspaces
16:44:06 <deiu> yes
16:44:16 <deiu> I'm just trying to see if/how this can be abused
16:45:01 <timbl> If everyone's pref file is in a similar place then the URI of the file itself should not give much away
16:46:40 <timbl> Not like   <#me>  space:preferencesFile <https://private.nsa.gov/groups/snooping/andrewMypreferences.n3>. 
16:47:22 <timbl> At the moment I cheat -- I have one on /localhost 
16:47:37 <timbl> so the link will confuse others
16:47:40 <deiu> you could have an acl for it though
16:47:50 <timbl> yes.
16:48:05 <timbl> definitely have an cal for it.
16:48:13 <timbl> s/cal/acl/
16:49:01 <deiu> I see
16:49:04 <melvster> ontology look great: public / private / shared ... that should cover most use cases ...
16:49:30 <bblfish> bblfish has quit (Remote host closed the connection)
16:49:50 <deiu> BTW, are these workspaces per application or "shared" between apps?
16:50:26 <melvster> could be either I imagine, the ontology doesnt forbid sharing
16:50:43 <deiu> would a calendar app be able to GET data from an agenda app?
16:51:07 <timbl> It will probably be a good idea to shave a bit of code which juts sets up a preferences file and a set of workspaces
16:51:25 <timbl> A trusted app can get any data a user can access
16:51:57 <timbl> "shared" for a workspace is 
16:52:04 <timbl> shred between users.
16:52:27 <deiu> aha
16:52:37 <melvster> longer term, I think apps should have finer grained permissions, so that it's not necessarily all or nothing
16:52:40 <timbl> Current thinking about string is between apps is we have spaces which are app-specific and places which are standardizes
16:53:01 <timbl> do  e.g. a map space any mail client can read and write to.
16:53:08 <deiu> I was thinking about cross-app workspaces
16:54:05 <melvster> I think we need delegated credentials in that case where the app has it's own identity and you tell it what it can or cant access, much like OAuth does for facebook / google+ etc.
16:54:10 <deiu> or workspaces dedicated to specific types of resources -- i.e. a photo album app will ask permission to access your "photos" workspace
16:54:29 <timbl> Two modes, one its you have a cross-app space, the  oethr is that one app starts using its own space (like the tracker does) and others just peek into that and join in
16:54:33 <timbl> extending it.
16:54:45 <deiu> yes, like the gps app
16:55:22 <timbl> delegated credentials -- yes -- well,  I think I need to be abel to say "I will allow Melvin to access this data only with this application".
16:55:26 <deiu> "Please indicate where I can save my files" kind of question
16:55:53 <timbl> Ihave that sort of code written
16:57:25 <deiu> granting access based on a specific app is difficult
16:57:50 <timbl> If you make a preferences file like http://pastebin.com/9aExuKW0
16:57:56 <deiu> it forces users to use app X over Y 
16:58:41 <timbl> well yes but what do you do when someone want to use an app off he web which will steal your data like an iPhone free weather app steals you  calendar as a privacy invasion?
16:58:57 <timbl> An arbitrary app might be maliceious
16:59:01 <deiu> timbl, that's the million $ question
16:59:08 <timbl> or it might "just" steak private at a.
16:59:19 <timbl> steal
16:59:24 <timbl> A trusted app won't
16:59:33 <deiu> I only trust apps I write myself :-)
16:59:36 <timbl> A trusted app isbenificent.
17:00:26 <deiu> well, I think this problem affects any kind of software system, even outside the Web
17:00:57 <timbl> Yes.
17:00:59 <deiu> you can have a trojan that sends data away, even if you use a trusted app
17:01:12 <timbl> BUttraditionally all software loaded on your computer was beneficent.
17:01:53 <deiu> BTW, a trust app also means some sort of trusted app store
17:02:00 <deiu> s/trust/trusted
17:02:25 <timbl> Beneficent here meaning roughly "would do what the user would normally be expected to want it to do if it had time to ask th user" -- i.e. no ads
17:02:57 <timbl> I think for me  yes useful to have atrusted app store but the installation process is important
17:03:30 <deiu> being able to install the app locally is very important
17:04:03 <timbl> Yes.   I may be able to e.g. set up a set of githb users which  I assume are beneficent nd if they have checked stuff in my client will run it with less of a installation hurdle for example.
17:04:03 <deiu> you can audit the app yourself and make sure you can trust it, since the code won't change
17:04:14 <timbl> You can also set up a review process.
17:04:28 <timbl> You can sign a cert for a given hit hub hash
17:04:50 <timbl> (which is feet in that it can be verified locally to still give the same hash I assume)
17:05:00 <deiu> I need to find a company to found me so I can work on it :-)
17:05:01 <timbl> s/feet/sweet/
17:05:11 <deiu> s/found/fund/
17:06:13 <deiu> right now it would be great to have an app manifest vocabulary
17:06:30 <deiu> otherwise you can't know what to expect from the app
17:07:58 <deiu> it's great that we have data.fm / rww.io as a base where people can install apps
17:10:01 <deiu> maybe I can package rww.io for debian, so people can install it everywhere 
17:12:36 <timbl> http://www.hhs.gov/ohrp/policy/belmont.html#xbenefit
17:13:06 <timbl> where I came across the word beneficent
17:13:37 <timbl> I don't want data.fm code and rww.io code to get too far apart 
17:14:16 <deiu> isn't presbrey working on a python implementation of data.fm?
17:14:46 <melvster> it may be possible to bootstrap the mozilla marketplace : https://marketplace.firefox.com/
17:15:46 <deiu> they have a really nice manifest system
17:16:01 <deiu> it can easily be transformed into an ontology
17:17:35 <timbl> I think presbrey might prefer everyone to switch to python
17:18:46 <timbl>  https://github.com/linkeddata ->  https://github.com/linkeddata/ldpy
17:19:07 <deiu> I would like that too
17:19:27 <melvster> deiu: there's a community group working on manifests, w3c has some work in this area e.g. widgets
17:19:57 <timbl> YEs, a whole spec which wasn't adopted.
17:20:30 <melvster> timbl: it's a pity, w3c widgets looked like a great spec
17:22:26 <melvster> perhaps it will be a good excercise to bootstrap the mozilla market place so that it's possible to install apps into a framework like tabulator
17:23:27 <melvster> most apps are free and dont require auth, which is nice ... and on unity they can even be downloaded as standalone desktop apps
17:24:57 <timbl> Hmmm the code in https://github.com/linkeddata/ldpy/blob/master/ld.py may be a one-file solution
18:08:24 <zuzak> zuzak has quit (Quit: Reconnecting)
18:08:31 <Zuzak> Zuzak (~zu@2001:ba8:1f1:f2f5::2) has joined #dig
18:08:31 <Zuzak> Zuzak has quit (Changing host)
18:08:31 <Zuzak> Zuzak (~zu@pdpc/supporter/professional/zuzak) has joined #dig
18:09:07 <Zuzak> Zuzak is now known as zuzak
19:01:21 <scor> scor has quit (Ping timeout: 276 seconds)
19:04:32 <jmvanel> jmvanel has quit (Ping timeout: 260 seconds)
19:05:05 <scor> scor (scor@drupal.org/user/52142/view) has joined #dig
19:08:23 <jmvanel> jmvanel (~jmvanel@199.0.88.79.rev.sfr.net) has joined #dig
19:48:02 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-226-107.w86-198.abo.wanadoo.fr) has joined #dig
20:05:36 <cheater__> cheater__ (~cheater@p57AEA1E6.dip0.t-ipconnect.de) has joined #dig
20:17:28 <timbl> timbl has quit (Quit: timbl)
20:18:01 <RalphS> RalphS has quit ()
20:24:56 <deiu> deiu has quit (Quit: Leaving)
20:58:23 <timbl> timbl (~timbl@host86-146-148-68.range86-146.btcentralplus.com) has joined #dig
21:08:45 <jmvanel> jmvanel has quit (Ping timeout: 276 seconds)
21:16:43 <scor> scor has quit (Quit: scor)
21:24:09 <scor> scor (scor@drupal.org/user/52142/view) has joined #dig
21:24:31 <scor> scor has quit (Client Quit)
23:12:46 <bblfish> bblfish has quit (Remote host closed the connection)
23:21:15 <betehess> betehess has quit (Ping timeout: 245 seconds)