---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 736b361..d2a3b31 100644
--- a/index.html
+++ b/index.html
@@ -168,7 +168,7 @@ Some of the practical implications of these principles are
 <p>We target POSIX.1-2017, but do not use the following features:
 <ul>
   <li>SCCS</li>
-  <li>UCCP</li>
+  <li>UUCP</li>
[message trimmed]

<m@kluv.in> writes:

> Hi EuAndreh.

Hi there!

> I am curious if you found any existing solution for the proposed database? I
> have been looking at irmin (which was mentioned in all forums) a lot lately,
> largely as substitute to libgit2, but recently also as a database.

I have written it down as a place to steal ideas from, which I plan to
do in the future as I mature more on the field, but irmin isn't a
solution, being written in OCaml.

andi@notmuch.email writes:

> Hi,

Hi there!

> Just saw your crate2nix code and it looks very nice and clean!

☺️

> Just a heads-up, since you might not aware of all the alternatives out
> there, there is a version from Eelco that basically does the same as
> yours but also handles git dependencies. I did blog about that briefly
> last month [1].

I see what to mean by being accessible, and it does make sense.

If done properly this might be the reality, where nobody chooses to
handle conflicts manually because they'd rather have a consistent view
by picking one of the possible algorithms that are available for them to
pick for each attribute. I'll experiment with this a bit, and if 
feasible, the "perpetual inconsistency" might be an internal view, and
something available for those who choose to customize their conflict
resolution strategy. This would be ideal, and perfectly aligned with
what you said on "the application educating the storage layer about how
to handle most of the conflicts it encouters". The unique URL you showed
is a tempting challenge to reach, and the domain identity being
teachable sounds indeed really powerful.

> The obvious problem of always favouring the local timeline is that each
> timeline would show different "primary" answers, but that's sounds
> somewhat reasonable to me to enable the database to keep working while
> offline, and while the conflict isn't resolved.

Also a possible ergonomics layer that can be built on top of some lower level
primitive:

Suppose we want to add a profile page to an app, but the user will be
able to edit their profile while offline.

Such profile page contains 3 parts: name, bio and links. Here's how it
could look like:

Here's what I was referring to when talking about "durable persistent
data structures": https://www.youtube.com/watch?v=Cym4TZwTCNU

I better get a POC so I can stop talking in "what ifs".

I was more focused on the storage implementation side of it, but I'm
considering not implementing a storage backend for this and just using
SQLite instead (more detailed in [0]).

Building durable persistent data structures on top of SQLite backed
storage is still a bit distant, but the model I presented could benefit
from a POC.

I'll try starting that instead of giving so much focus on storage, and
share it later.

[0]: https://euandre.org/2020/08/31/the-database-i-wish-i-had.html#fn:posix-sqlite

I started quoting many parts of your email, and things started to get
confusing. Each answer that I gave was referring to each other, and I
almost made a loop.

So I've rewritten everything as a single piece of prose. I added some
snippets of your text to better contextualize what I was talking about,
but I tried to address what you said directly. Here it goes.

# On migrations

I still don't think that I've insisted enough on *strict* schema growth.

The wiki page you pointed to reinforces that: it talks a lot about how
to coordinate attributes that changed their names, change in vocabulary,

Jeff Rhyason <jeff@rhyason.org> writes:

> It's amazing to see this discussion. Let's keep it going!
>
> My friend and I started Indelible[1] (now defunct) for a lot of the
> same reasons you want to build a datastore -- there aren't enough
> options for a datastore that's immutable, relational,
> highly-vaailable, and private.. We're still super-passionate about the
> ideas, love Datomic but want something a bit different, decided not to
> commercialize it and start more simply with just the data structure.
> We don't want a huge thing, just a library, to keep coordination down;
> the complexity doesn't spread out of the client.
>
> Where we are at now is we have a great versioned immutable B-Tree-like

Jonas Schürmann <me@jonas-schuermann.name> writes:

> Yes, exactly. The idea is pretty abstract and while I know a little bit
> about category theory I'm by no means an expert on the subject. This
> blog post [1] is a very down-to-earth, practical explanation how the
> concept of (co)completed categories can be applied to conflict
> representation in version control systems.
>
> [1] https://jneem.github.io/merging/

This sounds interesting, thanks for the link.