CouchDB is a meh local-first backend (storage).

Rather "thick-client local-first apps". As "thick-client" on it's own does not imply local-first, there may be a server.

Web apps can be thick clients.

Optionally they can be loaded gradually. E.g., with granularity down to components, as shown by ReactJS.

Having loaded the entirety - they can potentially work offline.

Making web app and its components content-addressable would allow to load them with no regard to location / some authoritative service.

Local Storage is not a good solution for persistence.

Sending git diffs as text over emails or other medius is the way it's been meant to use, if I'm not mistaken.

I.e., software engineers may be best keen to adopt lofi concepts.

Because it captures snapshots and not deltas.

There is no "shared master branch" in git. Subsequently, no authority that decides what's in it. Each git user is free to adopt any changes they see fit.

In an event when the sync service is down and you lose local copy - you won't be able to restore.

For this case it's better to have multiple sync options. Such as your other devices and incentivized third-parties.

Whereas it is the opposite in reality. Devices are the primary sites of intent they issue. And server is merely an aggregation site.

Given email is signed.

Git alone does not dictate how one transfers stuff.

Loosing a PHD paper, especially after it has been published and some other papers already referred to it / based their reasoning on top of it, would be a serious hit to humanity's knowledge. Sadly, this is the reality today, may happen.

Would be nice for lofi software to make it as seemless as replicating across chosen parties automatically.

E.g., in your account you linked your devices, and chosen them as replication sites. In addition you chosen a third-party, e.g., Web3Storage.

So you can use apps and rest worry-free about persistence of your data.

Even better if software uses known data model, such as RDF, and so you're not locked onto the tool.

Perhaps even better to capture your intent as events and have data models derived out of it. This way you're not even locked at e.g., RDF ecosystem.

I.e., don't rely on third-party as a medium to express yourself. Otherwise they're in control what you can express.

E.g., Twitter/X, Google Docs and their bans.

I have dread in my head every time I use cloud service that there is an issue about to happen. There will be a data breach, data loss, service becoming unavailable (e.g., they don't like you anymor, e.g., Github can block you from your private repos at their will), it's just a matter of time.

So I need to get my data out, back it up, if service been kind to allow for that. But that's a burden. It's a hidden cost you learn to recognize over time. May not be apparent from the start to everybody.

This needs explanation.

This stems from the design that there is a mutable place and some authority over it. E.g., a Google Doc, Wikipedia page.

Would be nicer to embrace people as primary sites of their intent. And allow to compose them. This way a person who would previously need to request changes to a doc, would simply have a kind of forked doc locally, where he would make the change. And that delta may be shared with the original doc's authors, who may accept or reject it. With no regard to their decision, the forked version stays as intented, with the delta.

I.e., docs are sites that aggregated some deltas. Have a site per person. Allow sites to exhcange deltas. This allows for having personal views on a subject.

Akin to how it's done in Git. If only it tracked deltas and they can be arbitrary.

I.e., NextGraph gets it pretty damm right.

Also RhizomeDB is this spirit.

For the cases when you do wish to send op to a remote party you'd still need a spinner. Given you embrace distributed compute.

Local-first has most responsive UX due to operations being performed locally, as opposed to sending them to the server.

Optimistic UI / Optimistic Updates may actually fail at the source being updated (suprise-suprise, the word "optimistic" is in the definition).

This breaks down the original intent transferMoney(Alice -> Bob) into multiple one. Thus we don't have atomicity, as shown in the paper.

Breaking down seems to be just one approach of how such events can be handled by OLEP though. An implementation detail.

It seems possible to achieve atomicity and isolation for such events, as described here.

We can treat partitions as aggregates of events.

Given there is Alice and Bob, and Alice transfers Bob money.

Then we have 3 partitions, that aggregate their respective events.

Event transferMoney(Alice -> Bob) would end up in all three partitions: Alice, Bob, Alice+Bob.

Event-processing logic may be different across users.

Bidirectional lenses as a way to integrate different data models.

Event-based systems allow for divergent views as first-class citizens.

Users are empowered to create composed views out of events of their choice.

I.e., collaboration as composition.

I.e., divergent views as first-class citizens.

I.e., DB-first approach does not have divergent view as first-class citizen.

time warp as solution for eventually consistent derived state out of events.

Alternative solution is to keep snapshots.

These two solutions can complement each other.

There are two culprits here: 1. Original intent (transfer from Alice to Bob) has been split into different intents (withdraw from Alice, receive to Bob)

I.e., there is no atomicity at the level of original intent, and subsequently there is no isolation.

1. Reads are executed on derived views (DBs) that are stale.

I.e., there is no consistency.

Instead we can have 1 event that describes the original intent. It can be complemented by withdrawal approval and receiving approval. This augmented event, in form of (approvedReception (approvedWithdrawal (transaction Alice->Bob)) can be replicated across the corresponding source account and destination account logs. This way we have holistic view on what happens. This augmented event can be replicated across source account and destination account. Leading to an eventually consistent states there. Since we have requirement on atomicity of writes this event belongs in Alice+Bob log. Where each event relating to both Alice and Bob end up. Alice log and Bob log depend on Alice+Bob log. Thus ensuring that Alice and Bob are consistent with regard to Alice+Bob transactions.

To cater for 2), we need to make sure that reads happen on top of the latest log entry. We can represent read as an event that depend on the latest log event. Thus, it'll be processed on DB state as of that dependent event.

Event logs allow for gradual processing of events.

Event logs represent deltas. Whereas DB's are snapshots. Deltas may be useful in order to get insight about intentions.

DB-first approach makes harder to reconcile happened events.

Only-once semantics for side-effects by linking side-effects to a checkpoint. Thus we have a kind of a commit with side-effects as of some checkpoint. They are processed only then. And having checkpoint guarantees that it'll be picked from this state, and so side-effects won't be issued twice.

This is not the same as idempotence of side-effects. It merely guarantees that side-effects is expressed only once.

It relies that event processing won't replay events before a checkpoint. This is not the case for all architectures. Some may use time-warp technique. Some may replay from the start.

Idempotency of side-effects as a solution for multiple invocation of the same side-effect (intent).

A solution is to have events idempotent.

E.g., to have events describe intent, and be content-addressable.

Then, the same intent = the same content-based id = noop by others that already received it.

Or use ID for a node in causally aware DAG as its hash.

why so?

This is akin to specifying "validTo". However, why remove "no more valid" commits? The can be of use for time-travelling queries? E.g., "give me the state as of that validTime". And performing such queries at time when something's expired could omit/filter it out.

those, that are not used in other branches

Huh, we're losing authorship this way. And commit deduplication.

why not have a removeAccess kind of commit?

Which would allow to have management of authorized parties without the need for creating a new branch.

how so?

Nice

We may end up in scenario, where a SPARQL tx that generated commits acrsoss multiple repos is only partially valid. In one repo it's commit is valid, in another it's consider invalid. Leaving us in a half-horse-half-zebra state.

commitAckDelay?

Transmitting an event twice is a noop when we have causal deps on events. Is this purely for optimization purpose?

Why have it if each commit has it's dependencies?

Why have secret? Is public key not enough to uniquely ID a repo?

So the brokers are not per pub/sub / repo, but per user. They are a contact point / API / gateway for that user.

These brokes take on two responsibilities: 1) overall network health 2) store-and-forward for specific overlay

They'd need to be incentivized. Stakeholder of responsibilities differ. 1) stakeholders are everybody 2) stakeholders are that specific overlay's members

How this incentive's done? Can IPFS services be used for 2)? Such as Web3Storage for store.

Since it's content-addressed, can peers agree on not keeping / pinning such content?

e.g., auth as DID that have public keys on it

CRDTs at the level of compute-as-data especially interesting imo

Still, a third-party can be authorized with access to data and asked to perform a query on behalf of user.

Semantic Web PubSub on top of libp2p?

Hmm, it seems that the proposed algorithm may terminate prior to reaching n, having found the latest dependency.

Additionally, algorithm can be restructured to complete in one pass, as "go through the log until you have found all latest deps". Then algorithm will have time complexity up to O(n). If I'm not mistaken.

As an alternative, perhaps keeping indexes per each variable may provide interesting tradeoff of time for space. UPD: this technique is described in 3.3.1.

It seems this can also be delayed up to read request. Since dependencies are needed to perform computation, and computation is only needed for read.

Could instead store the last AST and have that AST point out to dependent ASTs, making one AST DAG. Content-addressing of ASTs seems nice too

SQL may not be that familiar for web devs.

GraphQL and dot.notation is what they're used to.

Have authority to sign / process updates.

I.e., there's an authority, e.g., a shop, and it would need to process requests.

What the architecture can do is to abstract from URLs/exact endpoints, having ID of the authority instead, and abstract away transport layer, i.e., nodes in network talk with each other and we don't care how, all we care is expressing intents in data and they get passed around somehow.

Creating Invocation in order to delegate execution?

Good points.

couples produces with consumer. pubsub would be a simpler approach

Receipt, perhaps?

Task, perhaps

Have it as part of Workflow, signing over its fields? As in UCAN and Invocation spec

have REQUIRED decisionTime instead?

Perhaps an alternative strategy is to authorize side-effectful resources with "only once" restrictions?

E.g., issue UCAN that limits capability to 1 invocation.

E.g., one tweet.

It can be freely delegated by executor further, but only one invocation will be possible.

Decouple effect from pure compute? Make it "await" that compute.

ok != handle(error)

Memoization: ``` let allUCANs = findAllUCANs(UCANs, UCANRevocations) // a solution of UCANs that allows for op let opUCANs = findOpUCANs(op, allUCANs) let whetherWithinTimeBounds = withinTimeBounds?(opUCANs, now)

let whetherStillCan = stillCan?(opUCANs, opUCANRevokations, whetherWithinTimeBounds) // memoized // becomes false when revokations arrive or time bounds exceeded ```

att represents attenuation / restriction / narrowing down.

Perhaps absence of attenutaion (att field) is a way to represent "nothing's restricted".

Even if BGP evaluation engine is to cache results, merging low-selectivity BGP, b1, would incur costs of joining it with the merged-in nodes, b2 and b3. Which is one merge more than in the original BE-tree.

Shouldn't these be intersecting / common bindings?

I.e., for each common binding, they should be equivalent.

I.e.,

Ω1 |><| Ω2 = {μ1 ∪ μ2 | for each common variable Vcommon, u1(Vcommon) ~ u2(Vcommon)}

meant 2, I guess

meant 2, I guess

But we need tp2 >< tp3.

This example rewrite violates that, as optional tp2 will be added on top even if it doesn't >< with tp3.

By lifting optionals to the upper level this example of ((Pa ]>< Pb) >< (Pc ]>< Pd)) ]>< (Pe ]>< Pf) could be transformed into: ((Pa >< Pc) >< (Pa ]>< Pb) >< (Pc ]>< Pd)) ]>< (Pe ]>< Pf) in prefix notation with multiple args to functions, looks: (]>< (>< Pa Pc) Pb Pd (]>< Pe Pf))

]>< is kinda "enhancing".

I.e., can be evaluated on top of ><.

And so it can be lifted to the upper layer.

E.g., tp1 ]>< (tp2 >< tp3) = tp1 >< ((tp1 ]>< tp2) >< (tp1 ]>< tp2))

E.g., (tp1 ]>< tpo1) >< (tp2 ]>< tpo2) = ((tp1 >< tp2) ]>< tpo1) >< ((tp1 >< tp2) ]>< tpo2)

Or, if we allow joints to be a function of many arguments, in prefix notation, then: (]>< tp1 tpo1 tpo2) (]>< (>< tp1 tp2) tpo1 tpo2)

Overall, we can built a plan where non-optionals are evaluated first and then enhanced by optionals. And it makes sense to do so, it's the least computation-expensive strategy.

I.e., tp1 ]>< (tp2 >< tp3) not= (tp1 ]>< tp2) >< tp3 This shows that ]>< is not associative.

To show that it's not commutative, tp1 ]>< (tp2 >< tp3) not= (tp2 >< tp3) ]>< tp1

Also, ]>< is not distributive over ><.

E.g.,

tp1 ]>< (tp2 >< tp3) not= (tp1 ]>< tp2) >< (tp1 ]>< tp2)

Also, >< is not distributive over ]><.

E.g., tp1 >< (tp2 ]>< tp3) not= (tp1 >< tp2) ]>< (tp1 >< tp2)

Optional is meant to only accrete solution with values, never restrict a match for a solution.

Optional is meant to only accrete solution with values, never restrict a match for a solution.

Can also be used with multiple variables.

This, and BIND, could be expressed as CONSTRUCT, allowing for uniform representation of how data's stored - as triples.

E.g., sparql PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?discountedPrice WHERE { ?x ns:discountedPrice ?discountedPrice} CONSTRUCT { ?x ns:discountedPrice (?p*(1-?discount)) } WHERE { ?x ns:price ?p . ?x dc:title ?title . ?x ns:discount ?discount }

I.e., clojure (-> graph match-product-with-discounts derive-discounted-price (select-keys [:title :discountedPrice]))

This can be expressed as BIND at the level of query, sparing the need to introduce another special bind at the level of SELECT. Although SELECT may work on GROUPped solutions,

CONSTRUCT returns a graph, perhaps it would be of value to be able further feed it into queries, perhaps as GRAPH ?constructedGraph {query}

What's value of HAVING over writing it as FILTERing of a subquery?

There won't be duplicate values, yet we wrap with a multiset

Here, for ?s that are to be removed, they still will get LeftJoined with the optional. Seems like a redundant work. Perhaps filter first and then add optional?

From what I understand, OPTIONAL would behave like that only when appearing preceeding to non-optional clause. When it appears after a non-optional clause, it may only accrete values, but it would not restrict.

It would be possible to not block on updates if they were to captured with tx time. Then notifications would be able to grab the delta at tx time and do notification detection in parallel to coming updates.

If we are to have UCANs as delta restrictions, then this behaviour would be expressed automatically - all capabilities of UCANs in proofs would be delegated as is if no further restrcitions are specified.

Perhaps delegation arrows could be reverse to denote that they include / reference

Also a separate prf field would be of use to show for tracking delegation

Also arrows between capabilities are misleading, capabilities are not references

", that the issuer is authorized to"?

Is there value in having "*", perhaps instead we could make ucan-selector optional?

Not clear what's in it, perhaps annotate that it's a UCAN or substitute with a human-readable hash "bafy...UCAN"?

"Amplification by adding new caveat"?

"caveat"?

"Attenuates"?

"Amplification"?

This is contrary to the intuition behind caveats - they are restrictions, if no restrictions set - allow all.

"and" seems useful to have.

E.g., in the example above I'd read it as "and", actually json "mailto:username@example.com": { "msg/send": [{}], // Proof is (correctly) broader than claimed "msg/receive": [ { "max_count": 5, "templates": [ "newsletter", "marketing" ] } ] },

Could be unified with 1., having it as

A strict subset (attenuation) of the capability authorities from the prf field

"Operation"? The way it's named in incovation spec.

"Ability" or "Capability"?

"Abilities"?

What's value in having amplification?

Such composed tokens may become partially invalid if one of the proofs becomes revoked.

E.g., composing write access to / and /photos/ into / And having / proof become invalid would prevent access to /photos/, as it's been merged. Keeping them separately would insure more invalidation-resilient token. Although that is a point towards not merging rather than composition.

Also, composition may accidentally attenuate, as merged / access inherits timeframe of /, whereas timeframe of /photos/ could have been larger.

Also, due to difference in caveats merging by ability with no regard to caveats may lead to / access attenuate less-caveaty /photos/ access. We could try to determine if / caveats are more ampe than /photos/ caveats and merge only then, but that may be error-prone and complex to do.

Also proofs most likely will have different valid timeframes, so the composed token will be partially invalid at some time.

Seems redundant. What's value in having an empty map vs absent key?

"to"?

"identify with multiple keys instead of a specific identifier"?

This delegated capabilities did not attenuate

Could be additionally clarified, that delegation validFrom + validTo timerange should be contained in the timerange of its Proof UCAN.

exp may be mistakenly thought of "expires in some time" rather than "expires at time".

Perhaps use "validFromTime" vft and "validToTime" vtt or smth?

Why not optional, as with nbf?

.

bob?

Should it include "cause" field, pointing to updateDnsInvocation?

Should we reverse arrows to indicate that tasks depend / contain?

What's the value from doing so? Could Executor not run such task at all?

Can we represent Effect as Task?

In order to make spec more compact / generic.

of what?

"sync" and "async"

How is it different from Receipt?

Can it reuse await/ok approach?

updateDnsInstruction?

sendEmailInstruction?

createBlogPostInstruction?

Should it be in the same domain model as other byte values? E.g., [200 "giga" "bytes"].

Would it be useful for "memory" (and other byte value fields) to support number value in bytes?

Would it be useful for "timeout" to support number value in milliseconds.

It's a rather standard approach, may be easy to use.

Akin to reduce(previousDB, tx) => currentDB

^Q can be generalized as yet another T, denotade sa ^T (^ hints that it this "live" T may be applied on top of other Ts / maintains a "live" view).

This gives the ability for a ^T to depend on other ^Ts.

So, for each ^T in Ts, ^T(I(Ts)) = ^T(DB).

Additionally, DB is a snapshot. Perhaps ^T(DB) better denoted as ^T(Ts).

Thus the relation can be written as

ΔV = D(^T(Ts)

Additionally, D is akin to Δ, denoting it as such we end up with

ΔV = Δ^T(Ts), for each ^T in Ts.

And since Ts are versioned, ^T(TsN) implicitly has access to ^T(TsN-1).

I.e., TsN contains ^T(TsN-1), for each ^T.

Which allows ^T to be incrementally computed over it's previous value.

^T(^T(TsN-1), TN)

^T has function signature akin to that of reduce, i.e., ^T(accumulator, sequence element)

Classes / onthologies are not a core feature of the language.

It's how we have RDF and OWS - they're separate.

Classes can be build on top of pure functions and data - these two are the core, nothing else.

Perhaps even functions can be eliminated from the core. Function is a template of some computation. It can be baked-in into the program. Since names are user-level feature.

So we end up with data and ops on it as core, and some flow control primitives (perhaps or and and is enough). The rest can be built on top. As to what data to provide, multisets seem to be the most universal data structure / less restrictive, out of which more special data structures can be derived. And with advent of SSDs we are not limited by performance to sequential reads, so perhaps it'll be not all-to-crazy to switch to multisets as basic structural block of programs from lists.

Naming system is not the core part of a language.

Naming system serves two purposes:

1. Create structure of a program

2. Give a user-friendly interface

You don't need 2. in core of your language. How data (your program) is displayed should be up to the end-user (programmer). If he wants to see it as text, formatted as a LISP - his choise, if he wants to see it as text in a Java-like style - ok, Haskel-like - sure, visual - no prob.

Having languages as data allows just that. It helps us get rid of accidental complexity from managing a syntax-heavy bag of text files (and having compilers). E.g., how Unison lang have AST as data structure and text-based interface to tweak it.

Having code as data would also make run-time tweaking more easier, bringing us closer to the promise of LISP.

And also all the rest of neat features on top of content-addressing of code, that are now waaay easier to implement, such as incremental compilation, distributed compute, caching.

Have names as user-level feature, their personal dictionaries. Some will call reducing function reduce, some fold, some foldr, some will represent it as a triangle (for visual code management).

In no part is a core feature for a language.

The mainstream OOP is complex and has many responsibilities.

OOP as envisioned by it's creator is actor model - state management (state + managing actor) paired with linking actors together - a complex approach. Can be broken down to it's primitives. And OOP can be constructed out of them, if so desired, but not at the core level.

A good reference of language decomplection is Clojure.

Treating single values as a special case of multiple values is generally more performant.

IO is not the core of the language. It's more of an utility layer that allow the language to speak to the outside world.

Would be nice to have them at run-time.

OOP is an abstraction that is useful for a very narrow amount of use-cases, giving accidental complexity to others. Personally, I'd leave it out of the core.

This moves us away from the value of LISP as a meta-language that can change itself. We have macros at compile time, and not run-time. Having them at run-time gives us power we've been originally promised by LISP philosophy. Having no run-time dynamism would not allow for this feature.

I.e., having codebase as persistent data structure, tweakable at run-time sounds powerful.

A possible approach to that is having LISP hosted, providing a simpler interface on top of established but less simple and expressive environments. E.g., the Clojure way.

This is an effort to battle the LISP Curse. Would be a great movement, as it's one of the LISPs hinderspots. (another is adoption, tried to be solved by Clojure)

That would be great. And it is. Unison Lang gives us this power. Hope for wider adoption.

Having content-addressable codebase simplifies it a ton.

Perhaps an AST can be built on top of IPVM, akin to Unison Lang, but for any WASM 40+ langs out there.

Having common data structures would be great.

Atm each language implements the same data structures on its own.

Would be nice to have them protocol-based, implementation-agnostic.

Likely, IPLD gives us the common data structures.

Been true. Fixed in Clojure. Clojure is top-tier in integration with host platforms.

That's a good point. Again, not something inherent in LISPs. Possibly due to lack of adoption and the LISP Curse.

Not an inherent trait of LISP envs. And LISPs do have multiuser envs, e.g., REPL to which you can connect multiple clients.

Environments for LISPs are simpler due to simplicity of the language they're for. For a more complex language they'd be only more complex and hence more difficult to use.

Not sure I get that

How that is a trait of non-LISP environments?

More than that, it seems LISPs give you greater introspection. E.g., because of REPL. E.g., because of macros that can sprinkle code with introspection in dev environment and be rid of it in prod env.

How is that an inherent property of LISP environments?

Surely they can be extended with all the mentioned properties.

It does require effort to implement, and with sufficient resources behind an environment it would be wise to invest there.

E.g., Emacs has great docs. Clojure ecosystem has great docs and is a joy to work in.

I'd say LISPs have greater potential user-friendliness due to simplicity of interface. Simple interface + good docs is more user-friendly than complex interface + great docs.

And you don't need that much docs in the first place for simple interface.

As well as a simple, well-designed interface can serve as documentation itself, because you can grok on it, instead of going through docs. You mostly need docs for the mindset.

This is great. It's a desirable trait. But I don't see how that is a unique value available only for Non-Lisp environments.

What's wrong with that? Files are universaly accesable on a machine (and with IPFS - across the machines), seems to be a good design for the times. Any programs can interoperate through files - a common interface.

Files are 'caches' of computations made.

Sure, it would be nice to capture computations behind it as well, although that is not practical for back in times and is not that much needed.

But nowadays IPVM does just that at a globe-scale. And, thankfully, we also have a data structures as means to communicate and not a custom text.

I don't see what's wrong with that approach. Taking it further (as IPVM does) gives a next level of simplicity and interoperability, along with immutability/persistence - a game changer.

Well, that's a shame. Composability is a valuable trait of computer programs, at user interface included. The facts that they're not composable may mean that the problem domain is not well known, so it wasn't clear what are the components. Perhaps with time it'll become clearer. This is, interestingly is a non-the-right-thing approach. UI got shiped to satisfy the need without covering all the cases (integration of UIs). A lean startup approach. E.g., Emacs starter as non-composable and now turns into composable.

What's "right" is context-dependent. For programmers the right thing will be a simple and performant and mainstream etc. language.

LISP did not check all the boxes back then. Clojure now tries to get closer to checking what a programmer may need in production, and has a broader success.

Clojure had effort in it's design to make it a simple-interface thing, and it's excellent in that. It had effort in making it easy to adopt. So it's a well-design virus. The right thing. Virality is one of the traits of the right thing, in the context of production programming.

Performance is not the only metric of "goodness" of code. Simplicity is one of.

Often performance is not the higest value for business. It is especially so when we have ever-growing powerful hardware.

LISP allows for simplicity of interface. You can iterate on making the implementation performant, if you need so, later on.

Great, don't go 100% in. Especially since those last 20% take 80% of time. But please do have a good interface design in those 50%. It is to stay.

Unix is a mono kernel. C is a fixed language, whereas LISP can be extended with macros.

Composability is a trait of a good design. I'd expect The Right Thing approach to produce composable products, and Worse Is Better approach to produce complexed ones.

It is more fun to play with simple things. They're more rewarding.

C is more simple in implementation than a LISP. It's more fun to play with it's compiler. LISP is more simpler in interface than C, it's more fun to play with it as a language. (hence the LISP Curse)

I wonder why we don't have a C Curse at the level of compiler though. Or do we?

Huge doubts there. The original interface will stay there in some way or another. And it is complex. So users will pay the cost of it from then on.

E.g., Java is OOP, it introduces functional style, but OOP stays there. Some folks would like to switch to functional, but there is pressure from legacy codebase and legacy mindset around to carry on in the same fashion.

E.g., C is still a C. C++ and other C* are not far away in simplicity of their interface.

Unix is still a text-based chatter mono kernel.

It seems hard to impossible to change the core design, so in Worse is Better it stays Worse.

Can you go far with such a design before getting down in accidental complexity from having complex abstractions?

Abstracting away is the bread and butter of programming. In order to do it efficiently you need simple abstractions - simple interface. For this task interface simplicity is way more valuable than the implementation simplicity. E.g., you may have a functional interface on top of an imprerative implementation.

C is complex, compared to LISPs.

Unix has a mono kernel and a ton of C.

Are they the crux of simplicity, which is the highest value of Worse is Better?

.

.

Although an alternative approach of processing inputs as soon as they arrive is used as well, and may provide for better experience.

E.g., as seen in CS2.

This is a fine solution to discovery of a latest known version of a log of a machine. However, using it as a primary way would mean machines need to: store log in IPFS, publish it to IPNS, others need to resolve IPNS -> IPFS (and perhaps get notified in some way to know that there's change) and fetch from IPFS - as a solution for syncing state between two machines it will be pretty costly on time and computation required. As a solution to persist local log for other's occasional offline access - seems fine.

They can be made persistent by storing a log of messages to IPFS though, as OrbitDB does

The fact that they're not persistent by default may be a plus, as persistent is cost-heavy and can be done when required rather than always

.

didn't get it, I thought MINUS acts as disjoin

.

Perhaps immutability can be provided by having domain name of URL point to an immutable value, say content-addressable RDF or content-addressable log of txes.

.

Hmm. Query store may be eventually consistent with the command store. However, the issued query returned a stale result and there is no 'eventual getting the correct result' for it.

So we may end up in an inconsistent state no prob, where there is a command that transacts stuff based on a stale query.

Capturing query dependencies of a command in the command itself will allow for re-evaluation of queries on the consistent state.

CRUD operations can be captured as events in an event log though.

That's a strange restriction. Full-message connection has its cost, and I'd imagine peers would like to minimize that by being able to set it unidirectionaly and per-topic.

.

.

Can this be captured as SPARQL FILTER instead? Then we can keep on building the query and delegate filtering to SPARQL engine.

May not-zeroing result in unintended access to previously stored in that physical layout data?

E.g., if I intentionally create fully zeroed arrays and read previous physical layout.

This will be damm handy for ECS engines. The memory layout, shown in the associated figure, organizes data in the way such engines are querying for it.

Time-restricted feeding causes fat mass reduction, according to Dr. Satchin Panda.

It may be implemented as skipping breakfast, but it should not be breakfast necessarily.

However, there are benefits found in adopting early time-restricted feeding (skipping supper), as presented in this vid.

Not sure that's the takeaway of the study