gozala

We'll be doing first dialog community call on October 27. If you have any interest in dialog please stop by luma.com/ony3ob91

Just p2p replicated dialog db with @cdata.earth over via @iroh.computer ✨It feels pretty realtime

You can add friends to your contacts to sync with them

Loving ability to see members of the space in @tonk.xyz which also reflect topology of responsibilities. It also happens to be a representation of @ucan.xyz delegations chains. Space delegated ownership to founder who then delegated access to other members

Loving ability to see members of the space in @tonk.xyz which also reflect topology of responsibilities. It also happens to be a representation of @ucan.xyz delegations chains. Space delegated ownership to founder who then delegated access to other members

Space is a dialog database containing all the data, views and behaviors expressed via datalog through deductive and inductive rules. Feels like things are coming together nicely

Has anyone attempted an idea of @iroh.computer endpoint via CF Durable Object yet ? It probably can't be raw QUIC transport and implementation would need to be hibernateable to be cost effective, but something I'd be very interested in trying out

Here is an @iroh.computer teaser, showing web browser finding a iroh node (on my machine) replicating two dialog db's that you can connect to via WebRTC transport (without relays)

This prove of concept does something very cool, it public "secret" to create RTC offer / answer with 17.0.0.1 candidates on a port range using it like mDNS service discovery protocol and then allows you to connect with discovered nodes via Iroh over WebRTC transport extension

Here is an @iroh.computer teaser, showing web browser finding a iroh node (on my machine) replicating two dialog db's that you can connect to via WebRTC transport (without relays)

Thinking of coining "serviceless architecture" term to describe dialog's deliberate choice of syncing without server component which cost some efficiency, but prevents lock-in.

🤔I wish it was clear why UCANs alone not suffice here. Ability to revoke is important, but it would appear that addressing that would be simpler and more complementary. This isn’t a criticism, it’s desire to seek understanding

🎯 Need for shared indexes is what you run against when trying to decentralize. Not only we need shared index, but everyone just need a small slice of it. This was original motivation of dialog-db, what if we could collectively own shared index that you can query without having to replicate it all

Remotes are like git remotes as in you can (and should) have multiple of them, that way even some of them completely shutting down can not shut you down

🎯 Need for shared indexes is what you run against when trying to decentralize. Not only we need shared index, but everyone just need a small slice of it. This was original motivation of dialog-db, what if we could collectively own shared index that you can query without having to replicate it all

This is where prolly trees github.com/attic-labs/n... and g-trees.github.io/g_trees/ offered interesting solution allowing us to build shared index (At-proto merkle search trees are also in the same family of probabilistic search trees) which is core of dialog-db

🎯 Need for shared indexes is what you run against when trying to decentralize. Not only we need shared index, but everyone just need a small slice of it. This was original motivation of dialog-db, what if we could collectively own shared index that you can query without having to replicate it all

github.com/mikeal had a brilliant idea what if we remove servers and let clients just query index and read from networked storage

🎯 Need for shared indexes is what you run against when trying to decentralize. Not only we need shared index, but everyone just need a small slice of it. This was original motivation of dialog-db, what if we could collectively own shared index that you can query without having to replicate it all