Broacdast Channel API works on the same origin.

Perhaps user's ID for that RP can be a hash of userID + RPID.

Claims about one's identity (authorized devices), could be maintained by the quorum of these devices. Or by a quorum of one's devices and his friends.

DID is an id + a way to resolve associated to ID info (DIDDoc). Seems strange to couple the two. I'd like to have one ID and plenty of methods to resolve info behind it. A kind of MultiDID.

This would require having private key portable. Which is not secure.

Having "bold" mean some semantics, e.g., important.

Then they merge. Alice does not consider it important, Bob does -> render both. E.g., Bob's "importance" expressed as bold, Alices "not important" as grayed text.

E.g.,

"Ny is a great city."

Alice removes "great".

Bob wonts to replace it with "gorgeous", by removing "reat" and adding "orgeous".

Having merged:

"Ny is a orgeous city."

Begs for semantic intent preservation, such as "reword great to gorgeous".

That would be nice.

As well as preserving where ops come from.

Screams to have gossip-about-gossip. I'm surprised people do not discover it.

This much like Chronofold's subjective logs.

Do the docs need to be shared in full? The only thing we need is delta ops.

How that works is not mentioned.

I guess ops are collected into logs, per member, based on their IDs.

A step short from having gossip-about-gossip.

What stops him?

Uhh, I'd imagine "remove" would refer to "bold" annotation.

Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.

Syntactic intent is not preserved.

That would be better for user to decide.

I think a good default is to express semantics explicitly.

I.e., for Bob to not automatically state his utterance as important just because it's atop of Alice's, that she considers important.

If Bob tries to reword - ok. If Bob want to add - no.

Given Bold, Italic, Colored are syntactic representation of semantics that we do capture - they can overlap.

Moreover, in Bob's user-defined mapping from semantics to syntax, Bob's "important" can be bold, while Alice's "important" can be italic.

Again, let them capture semantics.

Say, "Alice considers "The fox jumped"" as important. Alice changes mind, only "The" is important. Bob considers "jumped" as important.

Result: Alice considers "The" important. Bob considers "jumped" important.

Color is meant to convey some semantics. Like "accent", or "important". These semantics can coexist, just like italic and bold.

So a solution may be to: 1. Let users express semantics of their annotations 2. Give user-customizable defaults of how they are to be rendered.

Ensuring, that semantics's render is composable. I.e., it conveys originally asigned semantics.

Good remark of syntactic vs semantic intent preservation.

Semantics are in the head of a person, that conveys them as syntactic ops. I.e., semantics get specified down to ops.

Merging syntactically may not always preserve semantics. I.e., one wants to "make defs easier to read by converting them to CamelCase", another wants the same but via snake-case. Having merged them syntactically, we get Camel-Snake-Case-Hybrid, which does not preserve any semantic intent. The semantics intent here are not conflict-free in the first case, though.

Make defs readable | | as CamelCase as Snake Case | | modify to CC modify to SC They diverged at this point, even before getting to syntactic changes.

The best solution would be to solve original problem in a different way - let defs be user-specific. But that's blue sky thinking. Although done in Unison, we do have syntactic systems around.

So staying in a syntactic land, the best we could do is to capture the original intent: "Make defs readable".

Then we need a smart agent, human or an AI, specify it further.

I.e., let's capture user's intent as ops, not their result.

Have locks on data is a nice idea.

But given we have dissemination/disclosure among friends only, do we need to encrypt the blocks? Given communication channels are encrypted.

Well, when sharing such a block off-group, you may skip transmitting its deps. In Social Networking that may be alright. And when off-group agent gets accepted to group, he's able to get the stuff below.

However, that does complicate piggybacking, as it'll be seen that the previously off-group agent has some block (but actually he doesn't have its deps).

Perhaps a sort of protobuf is better.

Goes against democratic principles.

A democratic way will be to raise a BAN poll.

I.e., an edge of a hypergraph is a set of vertices.

This is akin to a pub/sub topic.

Multiaddr could be used instead, to aid connectivity

Agent = process

Not necessarily, how to store received events is an implementation detail. One could dump them in an array on a side. Can be as efficient as array of pointers to events. Where idx of this array is event's position in total order.

Any correct implementation can be composed with any other (compatible) correct implementation, and it is guaranteed to be correct .

I.e., there is a possible further computation from y to y', as well as from sigma(y) to sigma(y').

I.e., from any TS' computable mapped state y there is a computable mapped state y'.

Any compute in a TS can be performed in an implementing TS TS'.

I.e., any compute in TS maps to compute in TS'.

I.e., any TS compute is translatable to TS'

I.e., any compute in an implementing TS TS' can be performed in TS.

I.e., any compute in TS' maps to compute in TS.

I.e., any TS' compute is translatable to TS.

specification is an implementation of a TS by a TS'.

empty meaning, noop \ self?

I guess any s has such empty transition for it.

Huuh?

?

S3 -> S2 ?

What does * mean?

Consensus is required for smartcontracts and governance.

Payments and social networking require weaker equivocation-exclusion.

Huh, such firewalls exist? I thought they can be hole-punched.

^

What stops a culprit to send off-group a message that is not his own? We can only achieve the "culprit detection" by addressing and signing every message we send to A. This is a lot of re-signing. And we won't have a convergent DAG.

And that is not enough if one's (or is it both?) behind a symmetric NAT.

Perhaps better to attach a new IP address to a message once it does change. What's the point in telling over-and-over the same IP?

^

More like an edge gives a communication path.

A->B (A follows B) - B can talk to A.

A<->B - B can talk to A, A can talk to B.

I.e., Equivocation exclusion is not required for social networking.

I.e., protocol creators are not responsible for how it's used.

^

^

^

Perhaps better to have a permissions mechanism that is generic to express both cases, and more, so folks can manage it flexibly as they need.

This couples two things: read permissions, write permissions.

Having them defined separately and explicitly, group's empowered with flexible controls.

E.g., as in OrbitDB's policies.

So this is a kin to pub/sub, with single authorized publisher.

"want" rather?

"need" would be for refs of a message you don't have. But then such a message could have been required to come with deps.

E.g., Airbnb that may refuse access to service because you're from country X, despite that host is willing to accept you.

I.e., collecting data of how processes talk is cheap and preserves what happens on the network. Consensus can be made locally based on that info. Damm simple, data FTW.

Strange that you need to have a friend-path in order to use r's coins. I'd expect r to accept&approve a message from me, given I hold his coin (which he can see from my message).

Why have signed coins?

Makes it possible to track which coins been equivocated.

But what's the use for it?

What's the difference between "you can't use these specific coins as they were equivocatedly used already" and "you can't use these opaque coins, as they are in equivocation"?

Later, at least, may succed given equivocation issuer have enough balance for both. Although then there's no point in creating equivocation in the first place. So nevermind, won't happen, except by silly equivocators.

Again, this can be derived out of DAG. Seems redundant.

It would somewhat spare computation, as one can check equivocation by following a pointer, but then he would need to ensure that both equivocated blocks are observed by a self-parent chain of the "DISAPPROVE" issuer.

What's the point of explicit approvals if it can be derived out of DAG?

It won't spare computation, as one would still need to go through DAG and ensure payment's balanced and equivocation-free. Can't trust the issuer of "APPROVE".

Great, so r-balance of p is derived by the history of ops regarding r. So no need for p to calculate it and add to every op, would be redundant. Not sure the derivation is the proposed protocol though.

Would be nice to have finality optional. As to not incur round-trip to a possibly offline r. Double-spends will be detected and punished. Given the value of double-spend spend is less than a cost - no incentive to do so.

This behavior needs to be specified more strictly.

I'd assume r would be in charge to explicitly describe how he wants redemption to happen.

More like "not being able", as it's not up to him, he can't reject redemption.

Why do coins need to be signed?

Why to capture 4? Ops like burn(10), mint(1) do the same, yet being more semantic, as they convey what happens, rather than the result.

E.g., when green has 3 green_coins, and we see send(1, green_coin, (to) black), send(3, green_coins, (to) green) did green just miscalculated his balance (should be 2), or did he sent and minted one at the same time?

That looks messy, accidentally so, it seems.

1. Green agent only needs to REDEEM(green_coin) op to convey what he wants.

2. Self-payments are redundant.

3. Links other than self-parent and other-parent(s) are redundant. You can derive anybody's balance out of their self-parent chain.

3.1 Other-parent_s_ make the order of received messages ambiguous.

1. REPAY is redundant. When REDEEM is received, and given one can indeed redeem (recepient has his coin at the moment of receival) - the REDEEM should be automatic. I.e., plainly observing that REDEEM been accepted by recepient is enough to derive out of it one of 1) it's a suffessfull redeem 2) it's a failed redeem.

Why does he need to explicitly accept? Can't it be done by default? Can he reject?

Why does he need to approve? It is a mean of equivocation detection. But it requires all coins going through its creator. Incurring latency and possible indefinete out-of-service as creator goes offline.

Why is it not optional? Like we can exchange coins with recepient directly, and he may come to redeem it later, if he wishes, detecting eqiuvocation at that point.

Some services, that offer say a cup of coffee, would be willing to take the risk of loosing $5 of value on to-be-detected equivocations. Since equivocators will be punished severily that does not worth 5$ of value. So they can be rest assured that nobody's gonna do that.

Now this example holds if coffee provider prices in currency other than its own, say bank's.

And banks are generally online. But still. Why force it? Let them do a round-trip to currency owner at their choice, a tradeoff that's up to them.

Why does red agent need to issue pay to itself?

What red agents holds after he transferred 1 black coin can be derived from history his ops.

We can't trust what he issues, he may issue to self 1000 black coins. So we'd need to go check history whether he computed it right.

But then again, if we need to do that, why issue an explicit payment to self?

The device of Alice may be offline, e.g., smartphone discharged. We can't assume constant connectivity.

Pricing in your own coins means personal coins may not match in value behind them. One may offer a cup of coffee for 1 coin, another for 5. Simply exchanging 100 coins with each other would mean one'll get 1/5 of value from this exchange. So 1:5 exchange would be needed. But how to know that in advance?

distributed ledger vs replicated ledger

Couldn't he spend less? I mean if he doesn't go below his minimal sustainability expenses, he can trade what's left.

An agent may create as many agent's coins as he pleases.

Sovereign cryptocurrencies allow getting a credit from grassroots. You can convince people that you're a good enterpreneur, they'll exchange their tokens for your yet-to-be-built organization tokens. Possibly exchanging with a discound from your organization, so they can make profit later on, when it's established.

The second supermajority is a set of messages that super-ratifies some message. But here we don't make use of super-ratification. Next leader may observe just one message that super-ratifies.

Didn't get it. I'd expect that all blocks created by by these guys would refer to their previous blocks. Here the definition seems to say that one guy needs to ref to another's guys blocks, which is not "mutual".

I.e., ratification is a transitive closure.

I suspect, equivocated blocks are excluded from |B|.

I.e., do not contribute their ratification to block b.

What happens when many users are offline?

(depends how many, if there's not enough to form supermajority - no messages will be created at all)

If there's say 1/3, then I guess it'll be 1/3 of fail-to-select-a-leader attempt.

Also, members could have different stake. Then there may be say 1/5 members that hold supermajority stake, they're online, but the rest 4/5 is not. Then, I guess, there'll be 4/5 failed-to-select-a-leader attempts, on average.

"supermajority that observes supermajority that observes the leader". How likely that there will be?

Uff, this gets vague. "Wait" as in "buffer received events"?

But then how do these events get propagated, when everyone's buffering? I thought only events that are accepted into blocklace are propagated.

What stops accepting events right away, and propagating them further? Defining rounds as Hashgraph does. Because this is basically the strive for the same end - a block gets r+1 round when it sees that supermajority sees supermajority.

The thing with this algo is that the communication/dissemination between rounds seems to be hidden / not included in the DAG. What' the point in doing so?

We have less information on our hands of what happened in the system, that may be of value.

Also, by not including communication we miss the oportunity to add more ops when sending stuff to others.

When f = 1/3, then supermajority is 2/3.

n = 3 f = 1

(3 + 1) / 2 = 4 / 2 = 2 (out of 3)

^

A wave may end without leder block elected.

What's the probability of that? Is it included in the reported results?

Hashgraph's voting complexity is exponential. ?

This requirement would help to find colluders.

I guess Alice would only need to send Bob events that she knows he does not know.

How that's done?

Bob could gossip to Alice all events he knows she knew, based on his hashgraph, but it's not the same as gossiping all events he knows she knows.

Bob may have a stale view of what Alice knows.

The more up-to-date view that Bob can get is when receiving an event from Alice.

That's not how git works. It does use deltas heavely under the hood, but it's derived out of snapshots, which is the primary data model.

Payload and timestamps are optional.

After sending an event to a random peer, on completion - pick another random one.

^ middle member send his third event to his left and right member. So it's not just "send to one random". How is that specified?

^

Since signature carries ID, referring by hash will not capture ID, wheres referring by ID will. Interesting approach.

^ I.e., we need to ensure validity of block's ops. This is a datatype-specific validation.

Hashgraph gives all of that, as it has signatures. What's new here?

Perhaps keeping track of to whom events are being sent will allow to collect evidence, that a node violates liveness.

Furthermore, this can be kept local, and only reported when observed that liveness is violated. I.e., "You said that you received my message, but from others said to me later, it wasn't included. I'm reporting you now."

Having collected > 1/3 reports - node can be considered to violate liveness.

In this approach, however, any >1/3 nodes can conspire and exclude any other node they wish, without evidence, "trust us".

One pair of equivocated blocks is enough to keep for that purpose. Having learned there are two - subsequent ones can be rejected on receival. Not all nodes will know of equivocator, and will send updates to it. So these updates may not reach the community. But eventually equivocator will be consensually known and excluded.

This is a tradeoff.

Alternative is to stub eqivocated messages, so the correct messages are passed around.

Here node refers to process / member.

Didn't get it

Somebody may do some work atop a message that's in fork. What happens to this work if the block gets excluded?

Also "exclude" may mean logical deletion, if we detect nodes that are in fork, we can skip transferring it's ops, instead placing a hash, since these ops won't be used anyways (and can be rather huge, up to a max allowed size), thus preserving causality by having a malicious block around, and saving on metadata by transferring the minimum of information for causality to be preserved. (stubbing content with a hash).

Not true for Hashgraph. Equivocation there is known as a "fork". Forks are detected and do affect the algorithm of virtual voting (these messages are not "seen", i.e., their ops won't be included). Hashgraph does not propose to reject these messages. I guess this is due to them potentially carrying valid ops from other peers. But overall, nothing stops ignoring Byzantine members or straight out excluding them.

Blocklase is a pure-op CRDT.

Causality is baked into each message, but more robustly, not as a version vector, but by hashes. Thus being more suitable for a Byzantine environment.

That's interesting. Block may refer to many blocks at once.

Curios whether Hashgraph's consensus can hold with it. It'll give inacurate timestamps. I.e., accuracy of how events been received will suffer. Perhaps we can only receive immediately events that contain ops that requrire a point of order. But overall, receiving and propagating further events right away seems to be a good strategy, since it captures more accurately what happens over-the-network. And it's more constricting, meaning it'll be easier to detect byzantine behaviour. Nodes are required to accept any valid events right away. Given we want to propagate events by gossip fast, we'd need nodes to accept and propagate their newly created event right away.

I.e., the approach of multiple blocks is not gossip-about-gossip.

There's a downside of having to accept right away. That is if we strictly comply to gossip-about-gossip, then event must point to other-parent. But if there's no other-parent, how do we get our local ops packaged and sent?

Perhaps a way is to ease the requirement of other-parent ref, then nodes can add local ops with ref to self-parent alone, and propagate them, will be alright even for a single keystroke op in text editors, although the metadata cost is somewhat high.

Perhaps metadata can be reduced down to signature. So whenever one receives an event with just signature - we know that it's an event with only self-parent ref. A well-known special case.

And when you want to accrete atop other-parent, you include a hash of it.

So the metadata cost is signature and, optionally, 1 hash.

Processing cost of deriving author out of signature, and verification is to be measured.

Virtual chain is a kind of global chain. Nodes converge into it. There should be a self-parent chain, where forks are detectable and considered byzantine.

But perhaps gossip-about-gossip is even better.

Well, ia is a hash. So it may be missing in B. Need to ensure that ia (and all it's transitive deps) are present in B before accepting it, adding to B.

E.g., use Reliable Causal Broadcast.

E.g., request missing nodes, holding to a node with dangling pointers before they arrive. Optionally discarding it if deps did not get fetched after a while.

^

So, nothing stops byzantine members to forge that they received some event from another node.

Can be catered for by wrapping events in a message, containing recepient. This captures more data of what happens on the network. Data FTW.

This is interesting. Finality can be derived per event / block.

Acks as first-class citizens of a DAG

Forks may exist in RB. Having learned that every learned of a payment and it had no forks - we can accept. But solely RB seems not enough.

Pure op-based CRDT just propagates ops, causality is preserved by default, guranteed by the messaging API.

If we have a stable add(v), and we receive add(v,t), the later can be made obsolete.

Causal stability - a given message will be in causal past of any yet to receive messages. I.e., there are no messages for any not yet to be learned that do not have a given message in their causal past.

Prepare phase won't be needed, if we preserve context of the op, e.g., via a hashgraph of ops. So any replica can derive the state an op's been issued on.

This is a stronger requirement than SIM-commutativity.

Ops are guaranteed to commute / result is the same with no regard to order of ops.

What stops making an op content-addressed, so it's deduplicated on multiple receivals?

A way to cater for eclipse attack can be to capture node's addresses in a hashgraph of that gossipsub topic. This way, when a new node connects to any of behaving peers, it'll get HG with addresses of others.

That will possute HG with unrelated to domain stuff however.

Y.js uses version vectors to sync p2p. Yet it's a brittle approach. No hashgraph integrity.

I don't see how Undo would mess up State Vector, being just another op. State Vector bit of that user would increase.

Would be nice to have truly unique ids. E.g., a public key.

Eats more space, but can be zipped over the wire. Given there are many ops transferred.

Also could be possible to create pubkey -> int mapping per-document, so it's damm more compact. That would require consensus on this map.

So, whenever there's constantly > 1 users offline on a doc - can't garbage collect / compact.

User may go offline for more than 30 seconds. The approach seems brittle

.

That's plenty of metadata.

Why three refs? CT showed that one's enough.

Also strange that deletion mutates an op, rather than being another op. Seems it'll be hard to manage it (undo/redo).

It's unique as far as user behaves, not creating ops with the same id.

Hash of an op would be a good id. Although it does not come with a counter. So counter, if we need it, is in the op.

.

.

.

Strange. I'd expect user's intent to be preserved.

That is another step of accidental complexity

Flew over my head

Chronofold seems to have what's wanted here

Uhh, strange approach at glance. I'd expect local changes to be preserved and received changes to be transformed and applied atop.

I don't see it. The OT and CRDT have distinct approaches on how to converge.

OT embraces subjective views, adopting ops of others to it.

CRDT introduces a distributed data model, that every user builds upon.

Rather, each object contains ID + clock + author + reference to another object & what not. Hefty on metadata. CRDTs focus on optimizing that. Perhaps another approach is to ditch the distributed model and embrace subjective op logs.

It makes a somewhat easy to grasp distributed model of a doc. Which makes it easy to sync. But building atop it client-side is a pain. It is complex. As Chronofold paper points out. Many projects folded, stating the CRDT model as the source of complexity that's been the cause.

Tombstones seem to step away from OT approach.

Where you have a separate from the current-doc representation. A DAG, from what I've seen. E.g., WOOT, CT, other CRDTs.

That seems rather harsh on UX. Surely it can be done better.

Here 1. server acts as the source of truth. And 2. clients try to compare-and-swap kind of.

But we don't need 1., clients are the source-of-truth, server is a helper middle man (that should be optional)

And having 2. we would not comply to any of the consistency models of OT - e.g., intents are preserved, happily merging.

This may not be the case. When peers know they're in sync - they can snapshot and dispose of the ops.

^

I don't see how that makes ops "admissible". Simply by reordering we won't get preservation of intent.

E.g.,

"abbcd"

peer1 and peer2 in parallel delete the second duplicate b.

No matter how we order them, we have:

[delete(3), delete(3)]

Intent of peers: "abcd"

Playback of log: 1. "abcd" 2. "abd"

Doesn't look like we preserved the intent - delete(position) is not admissible, in general case. It's context-dependent. No matter the order.

Well, it's not 'total order' anymore then, is it?

More like a subjective operations log. See Chronofold.

Then we can't have delete(position) operation. As it context-dependent.

I.e., ops need to be self-contained. delete(position) becomes delete(char-id) - whoa, now we have CRDTs.

I don't see that.

What CSM does, as it seems to me, is to specify/extend the "Intention preservation" of CCI.

Moreover, total order has nothing to do with "intention preservation". Ops that been issued in parallel can be put in total order - yet it does not give convergence of intent.

E.g.,

"abbcd"

And peer1 wants to change c to C.

Whereas peer2 wants to remove the second b.

[delete(3), delete(4), add(4, char: "a")]

Playing the ops: 1. "abcd" 2. "abc" 3. "abcC"

Intention of c -> C is not preserve, despite having total order.

This solution seems to aim to preserve intention (same result of an op in a different context) as trying to capture some host context and try to adopt op+some_context to the target context.

Which seems rather unnecessary if you would transfer op+host_context as is, the receiving party will be able to adopt it.

Clock, meaning Lamport one? Otherwise, with subjective clocks, I don't see how that works.

Exchanging deltas seems fine too

Does receiver need to trust the sender that the provided update does indeed contain all the missing ops?

Not convinced that it turned out simpler and easier than sticking with RDF stuff. May be biased with some prior RDF knowledge though.

Also, while a causal history includes every event, it's by a non-hash-based id. So no actual content is available.

Using hashes to refer to content would allow to be context-free. Any replica would know the stuff they're talking about.

Not compact, yes. Just two hashes are enough, in fact. ;)

Is this possible? I thought no.

It doesn't seem that RCT captures what's in subjective logs.

Version vectors would seem to allow it. But I think we don't have them in RCT.

Alternativey, have a vec for each author (yourself included).

So there would be a vec of author y, where unber k index is index in a's log.

Althought having no RCT to start with would be better.

Seems this is not on a hot path. Can be done in parallel, without blocking user's input. Once links are established, it can be atomicly applied. This will block.

RCS seems better, does not require splicing.

Isn't it already a delta weave?

Here weave refers to interleaved deltas (SCCS weave).

And splice refers to insert.

Meaning, that in order to add delta, we'd need to insert it in some position of a file. Which would lead to moving characters around. Hence the comparison with a plain string.

How this works is described here, in RCS, that seems to be a successor of interleaved deltas (SCCS) approach.

?

Got me confused, as previously b's been referning to an exact process. Perhaps a generic p could be introduced.

Resembles pointstamp of timely dataflow(?).

^

^

Nice that it operates on deltas. Although I wish the deltas would be the source-of-truth.

Huh. Would be nicer if that model implemented some sort of Watchable trait. Akin to Clojure's atoms. So others can subscribe to, and get notified on change automatically. So we can't shoot ourselves in the foot by forgetting to do that manually.

Resembles cursor abstraction of tonsky/rum

Perhaps we could reuse even larger repeating patterns, such as words, since in programming we tend to operate with such. (programming language reserved words, such as if when match, and defs a user creates, such as myCoolVar.

Though they could be split across multiple lines, as myCool- Var, although perhaps that is not a desired feature for an editor to do.

wgpu any better?

For a text editor, it doesn't seem like one.

As of now, there are displayes with 240Hz. (4.1(6)ms/frame)

But aiming to get smooth 120fps 4K is a good minimum.

However, for a text editor, being able to run 240Hz seems to be a resonable demand.

Or, rather, a client could 'reject' some contributions. I.e., be in power to accept contribution of others.

Having these ops contain author, one could undo their own ops. And I bet authorship is preserved.

The thing is that shared global stack is not useful to be shared, rather some stack can derived on each client in order to play.

But then some things could be played it paralell, So instead we're better of with some sort of AST. It could be derived out of global stack, but then we could construct an AST in the first place, having ops to come with their deps, as we have with CRDTs.

That is better, given that cost of AST is less than the cost of playing sequentially. I.e., cost of AST (increased size and complexity) worth the gainst we get from parallel play.

Powerful team. What's the outcome?

More like alter_error, or update_error.

I see map as a transducer, suitable to run on sequences.

Whereas here we don't have a sequence.

From what I understand, Tasks are not the top-level futures, but rather any Future that's being executed.

So there may be: async { async { async { }.await }.await }.await Where each async block is a Future, that's been wrapped by a Task on .await, and will drive to completion, be it returning right away, or hanging and calling .wake() on it's parent when it's done.

^