CW just so I can have more characters to describe 

@garbados @djsundog thanks for connecting and for asking!

I have a light wrapper around PouchDB-Server which does auth in Node instead of Pouch, and let’s me run one backend that multiple people’s multiple web apps can sync to, with each {person, app}’s data in a separate PouchDB on disk for isolation. I love it.

But it’s non-collaborative. As I was adding “friends” (person X can read my app A’s database), I realized I was thinking a lot about client-server and server-server API, just like Matrix or ActivityPub—person X might not have an account on my server (they might be running their own), so how should instances sync, etc., and recreating all that seems a lot of work.

What if PouchDB could write to a Matrix room whose access I could control via the usual Matrix affordances? If Pouch used a Matrix room to persist data, that could be cool! But I’m not sure how feasible that is.

A simpler alternative to PouchDB could be for each person’s app to just write plain events (that only make sense to that app) to a room, in JSON or plain text or whatever, and sync those events and recreate a database state from the event stream (like CQRS). This full database would just live in each client device, and not exist in Matrix: Matrix would just store the raw events.

So those are the thoughts behind my hastily-written toot :) in a nutshell, use Matrix as the persistence/sync/collaborative layer for local-first apps. Thanks for reading!

re: CW just so I can have more characters to describe 

@22 @djsundog that's interesting. i've been working with the hypercore protocol on a similar concept, of using a p2p datastructure like an append-only log to store events which, taken together by PouchDB or whatever, can produce the current app state.

i believe PouchDB is great for this because it gives you http replication out of the box. you can then use the plugin interface to support other replication methods, like following a hypercore or a matrix room. by making this capability into a plugin, you make it easy to mix in new replication methods, so a server can federate over new protocols without needing to homebrew that code.

i have a little project along these lines that i'm working on, but it's not so far along as for me to start sharing much about it.

re: CW just so I can have more characters to describe 

@22 @djsundog additionally, i'm taking a look at your project. that's neat!

re: CW just so I can have more characters to describe 

@garbados Thank you for these insightful comments!

I didn't know about PouchDB plugins so it's very interesting to see e.g. PouchDB-Dat. I'm investigating how straightforward it is to replace the HTTP transport mechanism with something else for syncing. (It's also incredibly sad to see PouchDB kind of abandonware.)

Hypercore would also be an amazing backend for PouchDB persistence! I'll think hard about how to write a plugin that supports arbitrary transports for syncing, that would of course be ultimate.

Not wanting to put all my eggs in that basket tho, I went ahead and added a read-only onlooker API to my little backend Gotanda so users can allow others to sync specific databases (I thiiink I did this securely but can't be sure). I finally began writing tests and unsurprisingly found a bunch of bugs 😅. I'm hoping to finish testing, add docs, and merge this feature to the main branch today or tomorrow.


re: CW just so I can have more characters to describe 

@22 @djsundog i don't know that i'd call pouchdb abandonware, since it's still receiving bugfixes and is otherwise feature complete. i'd call it more stable than dead, but it's true that some core maintainers have moved on.

still, i use pouchdb because it provides easy cross-browser storage and you get couchdb replication for free, which as you know turns into a lot of superpowers.

i've written pouchdb plugins in the past that wrapped the replication method to, for example, silently encrypt and decrypt records so remotes only see encrypted documents, and they're decrypted when you replicate back.

but i've also written pouchdb-hypercore that provides the building blocks for replicating pouchdb databases over hypercore, but there are some unanswered architectural issues:

currently i'm writing a database (i know i know, hear me out) that wraps pouchdb entirely so that you can use it as the db of record for working with lots and lots of hypercores. i wrote about the concept here:

that's the project i mentioned earlier, that's not so far along as to be worth much. but since it's relevant i thought i'd link something about it.

i hope some of this helps!

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!