paulgb

48 ms·

781.
by paulgb 4y ago
#1 your understanding of the DriftDB permission model is correct, but I’m not sure what declaring a new permission at runtime entails? Would I be creating a new bearer token for each room, and attaching the room’s permissions to it? #2 the
782.
by paulgb 4y ago
I’m sure there’s some of that, but is it really that hard to imagine that someone at the beginning of their career would get more out of being in-person? I certainly benefitted from that at the beginning of my career.
783.
by paulgb 4y ago
We’re a small team (3) who works in-person by coincidence of being local, but we are explicitly open to remote within overlapping time zones.
784.
by paulgb 4y ago
I suspect HN skews senior/established in our careers, but it’s interesting comparing the sentiment of people on here (almost universally pro-remote) with candidates I’ve talked to when we’ve listed roles. A lot of candidates, especiall
785.
by paulgb 4y ago
How do you prevent a malicious user from taking the wss endpoint you’re using, subscribing to a wildcard, and seeing messages intended for other clients?
786.
by paulgb 4y ago
Re. #1, can you elaborate? The tracking issue for this is still open[1]. As far as I can tell this is a hard blocker for any use case where a random user on the web can connect to NATS, since it means that user can wiretap any room without
787.
by paulgb 4y ago
The idea for DriftDB came from seeing people try to use Plane for things that it wasn’t intended for (e.g. simple WebSocket backends). DriftDB doesn’t depend on Plane if it’s hosted on Cloudflare. For deploying on your own infrastructure, P
788.
by paulgb 4y ago
NATS is great, we use it in another project, Plane ( https://plane.dev ). The reasons I didn’t use it instead of making DriftDB: - In NATS, unless you set up authentication, any user can subscribe to “>” and get a firehose of e
789.
by paulgb 4y ago
Good catch, this should be in the react docs but it's missing. Until then, it's pretty simple. You call `const presence = usePresence({})` and pass in any data you want, and the `presence` value that gets returned is an object tha
790.
by paulgb 4y ago
> What does "on the edge" mean in this context? DriftDB has a concept of “rooms”, which are essentially broadcast channels. By “on the edge”, what I mean is that the authoritative server for each room can be geographically loca
791.
by paulgb 4y ago
Yes, the concept of rooms is analogous to rooms in a chat service. One difference from IRC as a protocol (besides being over websocket) is that each connection corresponds to exactly one room (since different rooms may be on different serve
792.
by paulgb 4y ago
I haven’t looked at the queue specifically, but Durable Objects have a nice key/value storage mechanism that happens to map nicely. It would take a bit of munging to make it work for a stream instead of a single value, but I have a des
793.
by paulgb 4y ago
Thanks! My colleagues gave a talk last week on streaming data visualization that you might like: https://www.youtube.com/watch?v=0WyeZ9lKdSU
794.
by paulgb 4y ago
> So, I played a bit and it appears that if a client is disconnected and changes of the state happens when offline, once connected these changes will be applied to the other client who was having its own changes in the state. So its work
795.
by paulgb 4y ago
Good feedback, here you go :) https://github.com/drifting-in-space/driftdb/commit/8d946217...
796.
by paulgb 4y ago
The server itself speaks a very simple WebSocket protocol[1], so it could be used by anything that can speak WebSocket. The JS/React bindings that implement the actual data sync patterns (shared state, shared reducers, presence) haven’
797.
by paulgb 4y ago
> I think DB in the name is a little misleading due to there being no persistence (I assume?) but that is a small nitpick! Yes, I feel a bit guilty about that part. When I started it the design looked more like a traditional key/val
798.
by paulgb 4y ago
Compaction is where you take a chunk of messages and replace them with a single message. For example, one of the DriftDB demos is a counter ( https://demos.driftdb.com/counter ). State is synchronized by putting increment&#x2
799.
by paulgb 4y ago
I mean real-time apps in the colloquial sense - applications where two people see the same state nearly instantly. In the strict computation sense, it’s true that you can’t guarantee an upper bound for delivery of a message. This isn’t just
800.
by paulgb 4y ago
Ah, you’re right, I haven’t written that up yet. The tl;dr is something like: cd driftdb-worker npm i npm run deploy You’ll need to sign in to wrangler if you haven’t already, and will need to have rustc/cargo availabl
801.
by paulgb 4y ago
Yeah, it remains to be seen whether it is economical for us to keep the hosted version on CF. I suspect that for users who want to run their own geographically distributed instance of it, CF will be the path that makes sense for the majorit
802.
by paulgb 4y ago
Right, WebSocket is fine for a chess game, but you wouldn’t use it for a first-person shooter. If you do want UDP from a browser (via a WebRTC data channel) you first need a side channel to establish the connection, and DriftDB is handy for
803.
by paulgb 4y ago
As far as the server itself is concerned, it’s just a broadcast channel with replay and compaction capabilities, so it’s not directly concerned with conflict resolution. You could use it as a broadcast channel for CRDTs if you wanted to. Th
804.
by paulgb 4y ago
We created Plane, but we’re actually not using it for this! DriftDB stemmed out of realizing that a lot of the use cases people were coming to Plane for were simple WebSocket servers for which spinning up a container is excessive. Plane is
805.
by paulgb 4y ago
Yep, in fact, it was making a word game[1] for my family to play on zoom calls early in lockdown that sent me down the rabbit hole of synchronizing state in distributed systems. [1] https://word.red
806.
by paulgb 4y ago
The problem with MQTT is that most of the use cases I’m interested in involve a web browser as at least one party of the connection, and the browser doesn’t support MQTT. I could wrap MQTT in a WebSocket, but then I’d lose the advantages of
807.
by paulgb 4y ago
That’s essentially what I meant. The core database is separate from the Cloudflare parts, so it could in theory run on other edges (I want to get it running on fly.io!), but for now “the edge” can be read as “Cloudflare Workers”.
808.
by paulgb 4y ago
Exactly!
809.
by paulgb 4y ago
> but what about the time factor? Can it be on the order of hours? So far I’ve focused on use cases where clients are online for overlapping time intervals. When all the clients go offline, Cloudflare will shut down the worker after some
810.
by paulgb 4y ago
By “on the edge”, I mean that if you’re in London and I’m in Amsterdam, and we want to exchange messages, the messages shouldn’t have to do a round-trip through Virginia, they should go through a server closer to both of us. (Of course, if

More ›