#dat

(scriptjs) Managing identity is probably the biggest challenge with these kinds of apps

Why manage identity at all?

pvh: yeah that one. There's a couple of reasons we havent gone with it. Maf has said he prefers the predictable hash lengths in data structures. We also went with base16 because it's case-insensitive, which is important for URL domains. We could add support for base32 too, but if we add multiple encodings then we have a lot more complexity in the system

i don't have any opposition to *storing* fixed length hashes, just being able to hand them in in well-defined ways

this is also really not a complicated thing. what i fear is a propagation of different applications handling things differently because base16 is a pretty gnarly solution

cblgh: i'm trying out your chatmesh channel ... i don't see anything though

simpson: because i want to know who i'm talking to, sharing data with, etc

jimpick: aight ill go in now and post something

looks like im crashing now

[19:14:09] /home/cblgh/code/chatmesh/node_modules/hyperdb/index.js:272

var feedKey = self.feeds[head.clock[j]].key

i think something is wrong on my end ... i can't see anything when i type and i can't ctrl-c it

pvh: You can't know who you're talking to, only what keys they've shown themselves to possess. You can't control who has your data, only which friends you trust.

jimpick: did you run the first or second command?

Dat's a capability system, right? Why not stick to capabilities?

the first one starts a server, the second joins one

cblgh: the second one

aight

pvh: the problem with base16 being the length?

cblgh: substack said ... "if anyone wants to try, clone the repo then add to node_modules/hyperdb/index.js line 272: if (!self.feeds[head.clock[j]]) continue"

ohhh

totally missed that

simpson: capabilities arent a strong enough guarantee for some cases because you have to share around the secrets. Authenticated connections use secrets that shouldnt ever leave the disk, so I personally find them more trustworthy

it seems like i can type and do ctrl-c ... but if i hit enter to send a message, it freezes up then

capabilities are great in some cases, I just dont think they work for all cases

pfrazee: Sounds like you haven't read 'Capability Myths Demolished' http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf

pfrazee: from a UX perspective, yes

simpson: hey, i'm sure it wasn't your intent, but that felt like a really condescending way to try and share information.

heh yeah I have to agree. Let's assume I havent read it, what's the case against what I said?

pfrazee: Capabilities aren't different from any other PSK, e.g. passwords or secret URLs, so your argument would easily logically extend to not trusting any website which asks you to establish a password.

pvh: that's a fair point and I'd be open to looking at base32, but I do think it adds complexity because you have to consider encoding in your comparisons

pvh: Sorry, I'm not a nice person. I'll try to be more polite.

i wouldn't recommend passing around different formats internally

http://habitatchronicles.com/2017/05/what-are-c... 'If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition. That’s highly counterintuitive to most people, hence the related controversy.'

simpson: right but my argument is that, when I share a capability, I have to send the token to somebody

pfrazee: Yes. e.g. when you share a Dat URL, you must transmit the URL to the person.

simpson: and I dont always feel secure about that because my friend might not know that I dont want the URL shared

pfrazee: Then you shouldn't share it with that person.

Hopefully, your capability system has good support for *attenuation* so that you can share only a subset of your Dat with them.

simpson: that's not realistic UX. As a user, I just want a system that lets me say "share it with bob only" and that's that

Consider: What stops your friend from, upon receipt of the Dat URL, immediately cloning all of the data and then discarding the URL? They'll still have all your data and still be able to share it arbitrarily.

cblgh: hey, the chat seems to be working now

simpson: there's a conceptual difference in that action

cblgh: can you see anything on your end?

(Also, as far as 'realism' goes, this kind of attenuation *exists* in Tahoe-LAFS.)

simpson: the user making that duplicate is very conscious that theyre moving the data to a new identity that they control. It's not the same action as sharing the link

pfrazee: How so? Either way, your friend Bob has all your data and the ability to share it arbitrarily. A capability to data is equivalent to knowing the data.

And it's not like people don't grok the concept; anybody who's handled e.g. a Google Docs URL can understand the concept of URLs as caps.

yeah except that google docs' share URLs still carry some concept of secrecy

my default expectation of a share url for a google doc is that it still isnt something theyd want shared around, unless they say "please do"

Yes, a terrible mistake on their end that can be excused by most Googlers still not knowing cap theory.

whereas a dat site is the reverse

jimpick: nah i can't see you!

what the frek

cblgh: i reconnected, and now i see all the messages

pfrazee: i think what you're talking about is how software mechanism can support a set of social expectations in extension of hard crypto capabilities

i think perhaps i wasn't synced the first time

jimpick: ahh i did the same and now i see you!

raaaaaaaaaad

this is very similar to the chat example we build with hypermerge

pfrazee: much like pinkie swearing doesn't create an iron-clad mechanically enforced contract

jimpick: which, btw, has come a long way! pretty stoked to share it here soon

jimpick: i haven't seen that one!

jimpick: oh how is the electron / react-native stuff going?

im stoked to hear about dat stuff being developed to work on phones

i think it's pretty essential

cblgh: yea, it was awful

working now though

pvh: i ran out of time before the portland trip ... i'm going to work on it again on saturday

pvh: right

pfrazee: i think a lot about your notion that beaker browser can have soft "please don't fork this repo, it's not licensed that way" blocks

like sure you can just modify the browser to ignore the licenses and desires of the authors but that's 1) breaking the licensing terms and 2) shitty behaviour

`npx hm-chat 0485a7401efba5f7899b22aa7cbcf372884555a3a035bb14533f6c18d750f937` if you want to join a chat with me now

pvh: Somebody (probably me) will write a one-click fork button eventually.

Wait, Beaker's not open-source?

(using npx to get people to join a chat session is probably a security anti-pattern)

simpson: lots of people have done that in apps already

simpson: beaker is open source

taravancil: Ah, excellent.

simpson: yes, but only people who are willfully violating the desires and licenses of the authors and providers of that data will do so

pvh even if the content is not licensed to be shared, a user should be able to copy it at will anyway (fair usage and all that).

pvh: I didn't know Dats could be licensed. Are there docs on this?

IP can be licensed

simpson: there are not, just a discussion we've been having

dat is not a licensing tool

simpson, like anything else

pvh: yeah I think the soft blocks could be pretty cool

but i could put a LICENSE file into the dat, for example

pfrazee: we used to call this "locking the screen door" at songbird

Okay, so there *aren't* technical things in the way. Then yeah, this all sounds like a desire to ignore how data caps work. :c

it's p2p, of course it's going to be copied

still, there are a variety of differing desires for privacy and control over data

pvh: hah good term

one use case i'm very interested in is sharing data solely between my devices

Yes, but what is the point of desires compared to what the code can actually do?

p2p drm ftw?

simpson: social pressures and reputation (and law) all matter

To share data just between devices you own, don't give the Dat URL to anybody else, right? Just like with an SSH key.

the idea of the soft block is to have a way to specify your wishes without technical enforcement

and then the browser respects that within some limit

pfrazee, it could default to automated license detection (à la github) to show a "soft" block

pvh: i added a README.md to the hm-chat example https://github.com/automerge/hypermerge/tree/ma...

millette: yeah could do something like that

something like https://github.com/benbalter/licensee (ruby impl.)

pfrazee: I'm having trouble separating your position from that of some politicians who insist that the law can trump mathematics. Will you maintain your stance if Dat becomes a system with caps which do not just bear data, but can *compute* or otherwise authorize real-world actions?

simpson: basically there are multiple gradients of enforcement to these systems. We design the software to support authenticated connections, capabilities, and encryption for secure access-control. That's a required foundation. But beyond that, there are cases where either you dont want to go to the trouble of strict security, or strict security cant handle what you want

jimpick: that was really cool haha

people who publish photography, for instance, cant stop you from downloading the picture in order to see what it is, but they want you to pay a royalty if youre going to use it in your news piece / website / whatever

pfrazee: There is no gradient to capability invocation, though; either an agent *does* have a capability, in which case they may definitely invoke it, or they don't, in which case they can't.

cblgh: thanks!

pfrazee: In this particular example, there are piles of things that can be done, including not releasing all photos for preview, releasing only thumbnails or crops, watermarking previews, etc. all of which have in common that the data transmitted to the client is somehow mangled or lossy.

so paying for licenses or royalties, and having people not share if they havent paid, is a usecase which is easier to enforce socially than it is to enforce technically, barring some innovative work (I'd never say never)

So why are you encoding social norms into your technology, then?

simpson: social norms get encoded automatically

(Remember, cap theory developed in the context of virus-proofing systems. Virus authors have no regard for social norms!)

the norms you're encoding are that only what is technically enforceable should ever be used

the norms I'm suggesting we encode allow for people to make requests of each other

Hey, that's just how information theory goes. Again, it's mathematics.

simpson: all technology encodes social norms

in fact, all technology is built by people and for people. it's really quite remarkable when you think about it. mathematics on its own just sits there not really helping anyone and waiting to be put into practice.

pvh: What social norm is encoded by, say, the Fourier transform? (I'd answer that it encodes how our ears work!) Or perhaps the Y combinator? Is concrete a social norm?

pvh: My point is not that we should worship maths, it's that maths has laid out some rules and that those rules appear to behave in the absolute regardless of which computational model we pick.

Or, if you like, I'm trying to encode the social norm that people generally do not forget things which they have seen!

Anyway, I hope this was food for thought. I'm gonna go find food for lunch. Norm has a good short story: http://www.cap-lore.com/CapTheory/ConfusedDeput... Peace.

What's being encoded by this project is the removal of trust in social connections.

It removes trust as a constraint to software.

simpson ^

It's not so much if you can copy this or that (you can, in a p2p world - to look at something is to copy it), but rather what you can (or should) share.

if there's a soft block, it probably should go on the publishing side

In the concept of Generalized Certification Theory (see http://www.mcg.org.br/cie.htm), trust is simply “that which is essential to a communication channel but which cannot be transferred from a source to a destination using that channel.”

--Ed Gerck, PhD.

nicely put

Spot on. It's the best definition I've found yet, and I've been researching this for years. Ed is great. Must read.

See: "Trust as Qualified Reliance on Information"

oldie but a goodie https://www.youtube.com/watch?v=s7WDbnHlc1E (Trusted Computing)

I'm hacking up a CLI that layers trust axioms on top of dat.

damons: sounds interesting, but the site is not loading for me

Oh.. Sorry.. that link was a cut and paste from the article. It may be stale.

I'll find another copy.. sec.

damons: i'd love to hear more about that. one property of the system i'm building is that it composes a lot of hypercores and right now if you accidentally disclose one you can spider from there to anywhere referred to from there without anyone ever finding out

pvh: That's the problem I've solved. ;-)

an out-of-band key is something i'd really like to have

anything on github

?

Putting it up there now... just shaking out all the broken bits... and detritus from two years of hacking it together.

pfrazee: i'm going for lunch with alex russel of PWA fame and i plan to show him beaker. anything in particular you'd like the chrome team to know / think about?