#dat

(RangerMauve) :fire:

(RangerMauve) I love how it has message history out of the box. Honestly that's the only reason I use gitter instead of plain IRC (that and push notifications)

nice

(RangerMauve) It'll be cool if it could work in Beaker some day. Though probably not any time soon

What would need to happen for it to work in Beaker?

gotta get on this cabal bandwagon

(RangerMauve) isak1: The main issue is Cabal doesn't use the Dat API, it uses the primitives that are combined to make Dat. Beaker has a really high level DatArchive API so it couldn't be used to implement Cabal.

(RangerMauve) isak1: Basically, if this issue lands, we could do _anything_ https://github.com/beakerbrowser/beaker/issues/...

(RangerMauve) But I don't think it'll happen any time soon

(RangerMauve) In the meantime websocket gateways to the dat network would be enough to get cabal to work in browsers in general, I think

I see

we store a static web app on dat that uses webrtc + a signalhub somewhere to find peers

not quite dat, but def p2p

dat for hosting the js/html/css at least

Btw, of all these new-decentralized-internet projects that are knocking around, like dat, does anyone have a mobile client? Is there a reason why that is particularly hard?

scuttlebutt has one in dev under the codename of MMMMM

one big issue afaik is getting node to play well on both ios and android

voidcase: I think there are 2 reasons: 1) p2p means you open a lot of connections, which is not great for battery life. 2) dat default implementation is in node.js which is not the best choice for mobile. The Rust implementation will help a lot there

also, alternate transports like BT could be nice

@RangerMauve that's not accurate

we're going to be adding HyperDB and Hypercore APIs to Beaker

i don't think it would be too much work to take the underpinnings of https://dat-shopping-list.glitch.me/ and make it work with cabal... but doing a full fledged web chat ui is a big undertaking

voidcase: ^ see above

we're waiting for it to stabilize and so I'm not sure of the timeline, but I doubt it'll be any later than early fall

argh

voidcase: i wrote a mobile dat

(RangerMauve) pfrazee: Sorry, I meant that Beaker only had DatArchive at the moment. But either way, I think the secret sauce in stuff like Cabal is the peer discovery through discovery-swarm.

well, hypercore thing

cblgh: node on ios/android with nodejs-mobile is pretty good

(RangerMauve) There's https://github.com/bunsenbrowser/bunsen which basically embeds an instance of `dat-gateway`

(RangerMauve) But that still a work in progress to get the DatArchive API to work

there are some interesting problems to solve with the current discovery system

pvh: yeah, i think 5m was just rewritten to use that

yea, i have a cabal-like app called friday written with react-native

it mostly works

pvh: is it on github? I'd be interested in taking a look at it...

shibacomputer: yea, what's your GH?

invited :)

SHOW US WHAT YOU GOT!

pvh: shibacomputer

it's super broken but has a few interesting properties -- i use qrcodes to move hashes between the CLI / mobile app / invite people to channels

(RangerMauve) pfrazee: This part is what brings a whole new dimension to the p2p aspect: https://github.com/cabal-club/cabal-node/blob/m...

we do "private invite docs" between clients so you can send metadata to people through a document you both share

pvh: android only?

uhhh i think it should work on ios with a minimum of work but i don't have an iphone

i believe the only android cheat is that i hardcoded an android trick to find the writable directory to put your data in

@RangerMauve right. We'll take a look at what cabal is doing when we solve this for beaker

it's at the head of the nodejs-assets file

(RangerMauve) pvh: Could I get a link too :3 I'm planning out a p2p encrypted chat thing and I was also planning on using QR codes for discovery

sure

i haven't run it in a month or so since we're working on a new thing but i'm happy to field questions

pvh: totally taking a look at this. i'm very interested in p2p tabet apps personally

ultra thin lightweight clients, etc.

shibacomputer: oh you are going to be so excited about our new thing :)

though to be fair it's currently electron-only

i'll give a hint -- i'm currently experimenting with how to load react components from text strings

ah, cabal is using the key in the hypercore replication handshake... mafintosh what are your thoughts on this? If every node is going to have their own key, this shouldnt affect replication, right? https://github.com/cabal-club/cabal-node/blob/m...

cblgh: karissa: I was thinking about this approach-- there's also a general form `userData` buffer you can attach to the dat handshake

pvh: i know a little bit about it!

your designer was my referral if you remember!

yea, i've been using code i derived from component-playground

i do! :)

i'm glad ignatius is keeping you in the loop

btw, thanks so much for introducing us :)

(RangerMauve) pfrazee: I think userData is being used for the username, actually. When I first saw this trick in substack's chat-mesh demo, it was really exciting.

we'll be in berlin next week, would love to meet up

hopefully able to do a demo by then

pfrazee: ya we use that to propagate an initial nick (and peer key)

brilliant, would love to.

i wish i could've worked on it, actually

cblgh: making the user profile a hyperdb of its own is something we're experimenting with and very excited about on our new thing

shibacomputer: well, hopefully we'll have it out in the light soon

cblgh: because that way you just subscribe to the profile of other people and get their name changes and so on

pvh: mm! noffle is working on a refactor that uses multiple hypercores instead to add other properties easier

cblgh: you should look at what we did for pixelpusher

pvh: using https://github.com/noffle/multifeed & https://github.com/noffle/kappa-core

managing all those cores gets a little tricky

jimpick wrote us something we called multicore

@RangerMauve: cblgh: karissa: yeah, the thing that made me hold off on this idea is that I'm not sure how reliable it will be. Dat currently tries to connect to all peers at once, but it may start picking & choosing peers in the future, and it may also start multiplexing in the future so that handshakes dont happen. The multiplexing is especially a problem for Beaker, since we handle lots of dats

pfrazee: i hear that

yeah

multifeed and kappa-core are based off ideas from http://kappa-architecture.com

a new session in my current app with three people is something like 30-40 cores

pvh: I'm looking for a short-term peer discovery mechanism right now, so I may just go with this for now

pvh: right

one fun thing about using the same hyperdb though is that you can get changes from peers you aren't connected to

treating the append only log as the fundamental data structure and having cheap views built atop it

with which, pfrazee ?

e.g. changes from A can reach C via B; A -> B -> C

noffle: yes, we do that as well, but we put a CRDT on top

my general concern with the One Big HyperDB model is that you have a single discovery key, so you create a single namespace & sharing radius

pvh: this is some discussion about it https://github.com/beakerbrowser/beaker/issues/... - I'm just looking for a simple way for users on a dat site to discover each other

which is fine if you're, say, storing all the recipes from allrecipe or something, but not great if you want to share a note with someone

(RangerMauve) pfrazee: If you're planning on picking peers, try using XOR distance from their ID. I found that randomly discovering peers, and connecting to a couple of close ones, and one distant one, led to a decent minimal spanning tree showing up in the network. https://ranger.mauve.moe/graph-mst-viz/

oh god please don't do WebRTC signalling

@RangerMauve yeah you're basically writing a DHT there

pvh: read the whole discussion

heh

dang, i'm super late for lunch. gotta run -- back in a bit y'all

pfrazee: i'll be in berlin starting on saturday, sounds like we should have another get together

pfrazee, noffle, cblgh oh that's clever! basically using as an identity

pvh: yeah I'm sure we'll run into each other

mafintosh: yeah wdyt of my points on the reliability of that

pvh: are you coming to jsconfeu? That’s where we’ll be the whole weekend

(RangerMauve) I've been thinking about signaling over a DHT, and so far I've just come up with really slow pub-sub via polling.

taravancil: no! i'm just coincidentally in town for a team summit

we're getting the whole lab together mon-fri

oh pfrazee we have non-hypercore ephemeral messaging in pixelpusher

@RangerMauve I've got signalling working p2p in hyperdht

mafintosh: is that real now?

yuh has been for a while

pvh: cool what are you using for that?

RangerMauve: domanic did some work around efficient p2p broadcasting: https://github.com/dominictarr/epidemic-broadca...

just haven't deployed it at scale yet

pfrazee: we use it for presence and things like selection state

ssb uses this in "prod" now

pvh: heh sorry I mean what mechanism

just looking for the code

utp + hyperdiscovery ?

yea

cool yeah

that's the `PeerSocket` idea

well, sorta

for beaker

we reuse the connection we already have i think

yeah

pfrazee: tldr me on the reliability

wall of text

mafintosh: as dat scales, we're going to multiplex and also round-robin/selectively-connect to peers. That means handshakes will not be guaranteed for n->n in a swarm

of cours

e

pvh: oh right, perfect

pfrazee: point being? :)

pfrazee: it would be nice if this were slightly more supported, but this is a simple enough barnacle for our purposes at the moment

mafintosh: point being, replication handshakes may be reduced according to logic that's good for dat replication, but which is bad for announcing presence

ahhh

pfrazee: webrtc is a trainwreck and i would really really advise against it, particularly when you think about people who might be non-browsers participating in swarms / dat-based applications

i follow

pfrazee: something something gossip protocol

pfrazee: but if you go down the WebRTC path you get into a real nightmare of all the things webrtc does that you don't want