#dat

RangerMauve: well, don't hold me to that knowledge =0)

RangerMauve: konobi_: I don't mind :-)

RangerMauve: certainly happy to help talk it out to firm up some details in your mind, so that you can add a more succinct comment on the issue

pvh: are you in town much at all?

konobi_: i'm SF-based. always happy to meet up with folk

hæ o/

(austinfrey) @RangerMauve would be cool to build an electron menu bar app, where you can just toggle the websocket on and off

(RangerMauve) @austinfrey Apparently sbot already has a WS server installed, only accessible through localhost. :O That, combined with ssb-webify means that you can already have fully distributed apps over SSB.

pvh: ah... was thinking yvr for some reason

konobi_: oh, i am from BC but don't get into YVR terribly often since my folks live in the gulf islands

pvh: ah... we had twittered at one point about grabbing a coffee along with jimpick... *phew* at least it wasn't my memory on the fritz

(austinfrey) @RangerMauve ahh cool! I do like the idea of serving my web app over regular http, but then syncing in dat archives/hyperdrives through either a public gateway or local websocket server, so kinda a hybrid approach.

pvh: trying to find an additional person to talk about some experiments regarding dat and automerge in the systems world... you had sprung to mind as someone with a prospective interets ^_^

konobi_: tell me more! what are you thinking of doing?

pvh: unfortunately it's one of those pretty abstract, whiteboard type of things.

oh, we made an abstract whiteboard type thing: github.com/inkandswitch/pushpin

heh, I just saw that earlier... will have to float it past the diglife folks

it has some pretty crippling bugs caused by how we're opening hypercores, but those could be fixed without too much strain i think.

pvh: really neat, I'll be taking a look at some point soon... got a lot of brain dumping to do at the moment, so limiting myself at the moment. Since I'm still in braindump mode, much of what I'm going on about really needs in-person chatting for now =0(

(RangerMauve) CJDNS looks really cool! I remember seeing it before but I totally forgot about it. It'd be interesting to see how hard it is to integrate with Dat

(RangerMauve) It also looks a little dead. 😰

(RangerMauve) mafintosh: It seems cjdns also had the idea of using hashcash for thir DHT ids: https://github.com/cjdelisle/cjdns/tree/master/...

(RangerMauve) So it's probably a good idea. :P

rangermauve the idea floated a bit a while ago https://github.com/kewitz/dat-cdn/wiki/Content-...

I put all my dat efforts on hold though, I was expecting multiwriter (shortly!) and thought it was better to wait a little bit for that. Ha!

(RangerMauve) millette: Nice. I think that in the long term developers should be publishing their own data for their assets

rangermauve could be a nice service to offer to developpers: hook your repo here to have it published as a dat automaticall

y

I wasn't sure if using dat versions (abc+1, abc+5, etc.) would be a good idea to map to project releases, or if it should be more explicit.

(RangerMauve) millette: Yeah, I'm not sure either. I thought that folders for semver strings would be useful. Like `/~1.0.0` could redirect to `/1.0.6` using mounts. You could update where the mounts point using that. Maybe have the mount url point to `/src` at a specific version

oh, mounts. See, I know I'm missing out on a lot of stuff in dat space. I'll get back into it soon :-)

(RangerMauve) It's not a thing yet, but there's been discussion about it

(RangerMauve) millette: https://github.com/datprotocol/DEPs/issues/32

yes, I only glance at stuff now, haven't gotten my hands dirty in a while.

I'm still lurker

(RangerMauve) With mounts you could have your registry be a dat archive, and the individual authors could have their own archives for versions.

(RangerMauve) I think the goal was that with mounts you could replicate the mounted feed through the same connection as the main dat

(RangerMauve) So you could potentially be more efficient