Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pvh
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
1.
▲
by
pvh
1y ago
It does indeed turn out to be a difficult and subtle problem. We've tried to balance minimizing novelty (always risky in cryptographic systems) with achieving the various security and scaling properties we're looking for. We'
2.
▲
by
pvh
1y ago
Ideally, you would use existing commodity infrastructure but we have found none of it is really super fit for our purposes. Failing that, we have been developing an approach to low-maintenance reusable infrastructure. For now, I would advis
3.
▲
by
pvh
2y ago
Mechanical merge algorithms can perform better or worse on different kinds of conflicts (the specific example of editing deleted text is just one of many edge cases) but in the end no CRDT can decide if your merged text is what you mean t
4.
▲
by
pvh
2y ago
Hey, thanks! I don't know what's regressed here but I've emailed the support people for buttondown.
5.
▲
by
pvh
3y ago
Of course not. Kurt is up in Heaven now.
6.
▲
by
pvh
3y ago
Automerge does indeed work with live collaboration, though apparently not currently as efficiently as some other solutions. Everyone working in this space is exploring and looking for solutions that will work for users woth slightly differi
7.
▲
by
pvh
3y ago
Robust undo/redo remains an ongoing research project. Leo Stewen's work was presented at PLF 2023 a few days ago. It turns out to be a subtle problem to really get completely right, but in my experience you can usually get passabl
8.
▲
by
pvh
3y ago
The sync protocol does indeed calculate the delta between peers and efficiently catches both sides up. The backends you see are the ones I use, but the API is a binary blob key value store with range queries: supporting other stores should
9.
▲
by
pvh
3y ago
Please accept my unreserved apologies, Heather! No offense is intended. I can speak for everyone working on Automerge when I say that we've very much appreciated Matthew's work and have indeed spent quite a lot of time studying an
10.
▲
by
pvh
3y ago
Ink & Switch is behind it; or more expansively mostly Orion Henry, Alex Good, Martin Kleppmann, and myself. As an organization, we have been working on Automerge for about six years now. We also have a wonderful community of other contr
11.
▲
by
pvh
3y ago
The way I think about it is that if the data should always travel together it should be in one document. For example -- if your TODO list always goes as a unit, then make it an array of objects in a single Automerge document. On the other h
12.
▲
by
pvh
3y ago
Automerge is a library that anyone can adopt, and we are a research organization, not a product company. We have built a variety of projects with Automerge, both publicly and for use in private, including recently the markdown-with-comments
13.
▲
by
pvh
3y ago
The benchmarks Matt Weidner has been working on are great and outside scrutiny is always welcome, but I should note that I find there's an element of artificiality to them. In particular, testing the performance of the sync system whil
14.
▲
by
pvh
3y ago
Thanks, Scott. This API should make it much, much easier for folks to build with Automerge and kind of just encapsulates everything we've been doing in-house over the last few years.
15.
▲
by
pvh
3y ago
What fun, jake! I am really enjoying your series here. When we built Pixelpusher ( https://inkandswitch.com/pixelpusher ) that was the beginning of a long and ongoing journey into the user experience implications of CRDTs. Fo
16.
▲
by
pvh
3y ago
Just a note to suggest that giving away your hard work to those who will profit from it in the hope that they will remember you later seems like a pretty dubious exchange. Have a look at how that worked out for the folks who built node and
17.
▲
by
pvh
3y ago
To the former, curious people with an interest in how and why the world came to be as it is. To the latter, obviously "it" has improved, but ecosystem effects make certain changes very difficult and expensive to coordinate and wha
18.
▲
by
pvh
3y ago
Hey there! It's great to see more folks building more CRDTs. On behalf of the Peritext authors, Automerge, and Ink & Switch, welcome to the community.
19.
▲
by
pvh
3y ago
We tried Web Bluetooth in a project. It was extremely flaky. Notably it also only works as a server, so you cant peer two browsers over it either.
20.
▲
by
pvh
3y ago
Just so!
21.
▲
by
pvh
4y ago
Thanks. We'll fix that before the next one.
22.
▲
by
pvh
4y ago
The article has quite a few performance numbers in it. The short answer is that it's much, much faster but that we will continue to pursue improvements pretty much forever.
23.
▲
by
pvh
4y ago
In fact, convergence is a very easy property to preserve in all distributed systems. The trivial but technically valid version of convergence is to throw away all the writes and always return an empty document. A "last writer wins"
24.
▲
by
pvh
4y ago
I prefer to think of Automerge as a form of version control: because the full history is retained, if you don't like the merge you can decide what you want to do instead.
25.
▲
by
pvh
4y ago
Wonderful postmortem, Paul. Appreciate you taking the time to reflect and share what you learned.
26.
▲
by
pvh
4y ago
These experiments are not the products we think users would adopt if they held them in their hands. They are more like the studies a painter or a sculptor might do as part of planning a more ambitious piece. It's hard to predict where
27.
▲
by
pvh
4y ago
For one exploration of that direction, please see our paper Crosscut: https://www.inkandswitch.com/crosscut/
28.
▲
by
pvh
4y ago
We may in the future. The RSS feed is a good long-term bet, and in the past we have posted on Twitter at @inkandswitch.
29.
▲
by
pvh
6y ago
It's a good name, thanks for sharing it.
30.
▲
by
pvh
6y ago
Databases should add support for lenses and also support type conversations, column relocations, new default values, and everything else a user might need.
More ›