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

Loading phase does increase muscle creatine levels drastically and it relies on ~20g/day. So there are effects from high dosages.

That may not be correct.

According to this figure, metabolic changes that increase absorbtion begin to appear during the train. If we are to take advantage of them perhaps we'd like to have peak creatine level at that point. However, it takes about 45 minutes for blood creatine levels to peak. Thus, it may be beneficial to ingest creatine 45 minutes prior to the train.

.

To me Trusty URIs seem to have complected two concepts that make it bad at both.

These concepts are: mutable name + immutable content.

If you care about content-based addressing - then mutable name as part of it is of no value.

If you care about resolution of immutable content from a name - you're locked to the domain name service. Whereas there may be many parties online that have the content you want to get and it could have been resolved from them.

To me it seems IPNS got it right, decoupling the two, allowing mutable names on top of immutable content.

So you can resolve name -> content-based name, from peers.

So you can refer by content-based name.

So you can deref content-based name, from peers.

It seems by maintaining a 'blacklist' of removed entries per DMC we can both preserve the log of ops intact and remove enformation of the removed log op entry.

I'd imagine it's a MUST. Otherwise replica may receive content it just removed and happily keep on storing it. Keeping such 'blacklist' is an ellegant solution. Such lists are ever-growing however and perhaps could be trimmed in some way. E.g., after everybody who's been holding the content signed that it's been removed. Although even then nothing stops somebody from uploading the newly deleted content.

I guess another solution would be not to delete somebody's content but to depersonalize that somebody. So content stays intact, signed by that somebody, however any personal information of that somebody gets removed, leaving only their public key. That would require for personal information to be stored in one mutable place that is not content-addressed.

That is a valid concern.

Perhaps we could have them both - partial order + removal of entities.

I guess it could be achieved by having op log and have a 'remove entity by its hash' op. Logs would not preserve data for such entities. However, in order to not re-hash log entries from the 'removed' log entry onward logs could keep the hash of the removed entry (but not data).

Maybe that's the way removal's done in orbitdb.

Speaking about mutable graphs, signing ops seems to be a superior technique compared to signing entities. As when signing ops triples gets signed, giving finer granularity. So there may exist entities that are combined out of triples that are signed by different authorities. Finer profiling.

Reifying key addition to be yet another op seems like a good idea. More generally it's about managing container's meta in container's state. One great benefit from it is that we have meta-ops and ops converging.

Perhaps having determenistic order for operations would sovle that problem. Then if key revocation happens before the op with that key - the op is dropped, if after - preserved.

Akin how ops are ordered in ipfs-log.

That requires key revokation to be reified - to be a plain op log entry.

Also it's mutable - server authorities have moderation powers.

Archetypes seems to be a kind of index. However, for the example given that index does not get used for its purpose. It seems a more fit solution would be to keep an index of entities per a set of components that your code actually filters by. E.g., such sets would come from Systems

We may remove it, as this reference was meant for internal use

We can rephrase it as: "Benefits from using Open Collective with Carbon Units:"

To be more professional we can write it in a more correct way: Open Collective

We can replace it with the full name: Open Collective

This can be removed.

Can be rephrased to: "Provide more services to Web3Workshop participants"

Can be rephrased to: "Close integration with ProtocolLabs project-raising ecosystem"

Can be rephrased to: "Attract customers that want Web3 applications"

.

The amount of quads in a source may be ever-growing.

Then we couldnt't count them. Is that a problem for Comunica or will it handle infinite streams fine?

I.e., stream, returned by match() keeps accreating with new values (e.g., as they are being produced by somebody).

Can't Comunica count quads as they arrive through the stream returned by match()?

Can the DELET clause be right below the above INSERT clause? So we don't need to repeat the same WHERE twice.

Also would be nice to have transactional guarantees on the whole query.

.

.

An ideal design seems to me to be the monorepo pulling from its dependent repos. It would allow for granular codebase management in repos, yet you can have discoverability via the monorepo. Also it would not complect repos with knowledge of the monorepo.

Having more aligned developers improving PL Stack is a #1 goal of EngRes in 2022.

Corps optimise for money. Giving away money for nothing in return goes against their nature.

.

An alternative domain model could be: {"a": "/a.js" "b": "/b.js" "path1": {"a": "/a1.js" {"path11": {"b": "/b11.js"}}}} This way path to a name is a 'scope'/'namespace'. Also we're spared the need of "/" in scope's names. It does look harder to parse visually than a flat model..

An alternative domain model could be: {:imports {} :scopes {:imports {} :scopes {}} This is more verbose, but more uniformal.

Bytes could be treated as an entity and resolved by a CID.

Datomic may learn at query execution time that it's a ref attribute, I'd expect it to be able to resolve a ref by it's id in such case..

.

Having modifications done to the actual entity in the db results in reactive behaviour.

E.g., you have an app called "Test App", and you display "Test App" in navbar in place of logo. Also you have a form that lets you modify it. When you modify "Test App" to "My Supa Test App" it gets updated in the navbar as you type (and across all other places). That may not be what user wants, as likely they want to set a new value. This is akin to a problem of validation, when we don't want to show "field's incorrect" when user did not touch it or is touching it.

Perhaps having "dirty" form state kept separate, and being the subject of modification would be a solution to that, having the actual used value in DB pristine. I.e., swap "dirty" and "pristine".

Also may contain inferred-input (seems it's pathom's effort to guess what's the input by analyzing fn params destructuring).

Also may contain docstring

Lists only the required attrs, optionals (via pco/?) will be listed under optionals.

Can't we pass it via --share as we did with others?

Didn't we already passed XAUTHORITY env via --share ?

Couldn't we add a symlink from /lib64 pointing to /lib of this environment?

Why not /lib instead? Seems to do exactly the same, as there is no difference if /lib comes from a stand-alonely built environment or this one, manifest is the same.

Why?

Could it be solved in a more ECS fashion by having a system that manages other systems?

That would require to have systems as entities, however.