DID Portability (i.e., the capability to rename the DID string without distorting the SCID and DID history) will not be allowed to prevent duplicity of DIDs.
So, your ID isn't actually yours.
Because "your" ID is tied to a domain name, and domain name isn't yours, but rented, which makes you at renter's mercy to allow you to use "your" ID.
Cool.
n − f events from kthbase layer
^
Mysticeti [3 ] builds on Cordial Miners and establishes a mechanism toaccommodate multiple leaders within a single round.
^
stronglySee(x, z)
^
The root password of a cluster node is required for adding nodes.
From GUI, right?
All nodes must be able to connect to each other via UDP ports 5405-5412 for corosync to work.
^
The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably. While on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms.
^
pvecm create CLUSTERNAME
^
This private key must be copied to every processor in the cluster. If the private key isn't the same for every node, those nodes with nonmatching private keys will not be able to join the same configuration.
^
This specifies the fully qualified path to the shared key used to authenticate and encrypt data used within the Totem protocol.
^
Which IP transport KNET should use. valid values are "sctp" or "udp". (default: udp)
^
Encrypted transmission is only supported for the KNET transport.
^
KNET. This is a default and recommended transport introduced in Corosync 3.
^
The nodes need to be able to talk to eachother for the clustering to work. I know in older versions it needed multicast, not sure if that's still true. I believe some people have had success setting up nodes to vpn to eachother, and using the vpn as the cluster network, but it was slow.
^
The problem is neither unicast or multicast. It´s the latency between nodes that has to be < 2 ms in order for corosync to operate properly under heavy load. Fabio Click to expand...
^
corosync-cfgtool -R
^
Anonymity
This got me confused at first.
It does not mean that we don't know who cast a vote.
What it means is that each vote has equal weight.
Since everybody knows voter->vote it may affect how others vote. E.g., some agents may vote as another agent voted.
This cannot be solved by tech, as they may communicate out-of-band to coordinate.
But a futile attempt may look like: establish a blinded shared secret (DKG, every member knows public key, in order to restore secret key they need to cooperate).
Encrypt your vote + nonce with public key, producing a "blinded" vote.
Once everybody casted their blinded vote, cooperate so all are able to unblind the shared secret (private key) - everybody can unblind all votes.
This, however, requires that everybody casts their vote. As it's unclear whether vote has passed for any subset of blinded votes. So not only it's futile in its effort but also limits usability down to none, as any 1 uncooperative agent will block voting de-facto.
these differences could circulateand overwrite each other repeatedly
In a simplistic implementation of shared mutable state atop gossip - could be so. In any CRDT they'll converge to the same value.
A certificate authority or web-of-trust canhelp establish verifiable identities.
Verifiability != credibility. Pub key is a verifiable ID. Is it credible? That's up to you to decide.
Cassandra’sdesigners note that gossip only works when operations are commutative or ordering is not needed.
Well, they're wrong
Gossipsacrifices consistency for availability
Ehh, it doesn't? It's just a mean of passing info around. You could have one "master" machine and a gossip network that receive updates to its state. You could have a distributed consensus algo atop gossip, so every peer has a consistent ever-growing tx log.
If yougenuinely need linearizability or total order, Gossis isn’t the right tool
Linear order can be built atop gossip, e.g., Hashgraph consensus algo
Gossip will deliver updates out of order
Not necessarily, it's possible to have causal delivery with gossip
the compu-tation cost of KV caches is quadratic to the input sequence length
Findings suggest that as long as all documentsfit within the extended context length, traditional RAG systemscan be replaced by these long-context models
Ehh, man, [7] finding is that Self-Route efficiency is comparable to LC with way less tokens used.
based only on the provided passage
Meaning, LC is just pasting all context as text, it seems
This is differentfrom our findings, possibly due to consideration ofstronger LLMs and longer contexts in our work
long-context prompting isstill expensive due to the quadratic computationcost of transformers regarding to the input tokennumbers
A protocol stack (or protocol suite or protocol architecture) is a collection or group of subprotocols that work together to achieve complete communication between two or more computers connected in a network
discovery process locates the desired file then leaves thepheromone to help subsequent search requests
ndeed, we consideredthe mobility of the relay peers to ensure the link stabilitybetween the query initiator and the peers that have therelevant documents
to avoid, among otherproblems, the ‘dead sailors problem
In KERI context, it's validation of a new current threshold (on rotation), such that it's possible to satisfy it.
σ-supermajority includes a majority of the correct agents
UDP
Um, how is UDP different in overcoming mentioned vagaries?
If both behind symmetric NATs - still impossible to communicate. And hole-punching may be required for other NATs. Since receiver's NAT likely will drop packets from IPs that receiver wasn't sending packets to.
the blocklace is a Universal Conflict-free Replicated Data Type
The only way to know it has heard everything is to coordinate withall the other machines to establish that fact.
10,000 TPS
The use of a DAG-like structure to solve consensus has been introduced in previous works,especially in asynchronous networks. Hashgraph [ 4 ] builds an unstructured DAG, with eachblock containing two references to previous blocks, and on top of the DAG, the miners runan inefficient binary agreement protocol. This leads to expected exponential time complexity
What kind of complexity is meant here?
I guess voting, as witnesses of r+1 vote on each witness of r. But that's n^2, quadratic, and can be computed incrementally..
Latency is somewhat logarithmical as f(nodes) https://hyp.is/1q-pjhaiEfC4ggdV4IIKxA/arxiv.org/pdf/1912.05895
procedure depth(b):23: return max {k : ∃b′ ∈ blocklace with a path from b to b′ of length k}.
Figure 4:
Upon receiving 𝑛 − 𝑓 1-votes for 𝑏
the use ofleaders is to be avoided if possible, since leaders who are offline/faulty may cause significantincreases in latency
We can generalize the IID to an interaction context header, which may contain the IID plus any other information beneficial to gluing together the messages in an interaction.
This information (IID) seems to be useful as a "hint" to the receiving party, so it can lookup the interaction. Storing it / having it as part of a signed content - seems redundant, given causality is part of content already.
Furthermore, note that A does not need to know the B side of B's relationship with C, and B does not need to know the A side of A's relationship with C.
Doesn't A need to auth C0 to form relationship with C1, which A knows is in relationship with B1? (mayb it's not on the record, but I thought that A and B need to tell each other their relationship with C, so each can auth C0 and C1 to befriend)
letter of introduction for a new relationship
Another flow may be for a common friend to introduce his friends to each other.
E.g., given Alice <> Bob <> Carol
Bob could share Alice's AID in DM to Carol, and Carol could request Alice to befriend, which will be mediated by Bob.
So Bob recieves in DM "I, Carol, want to befriend you, Alice, via C1", and forwards it to Alice.
This may be encrypted to Alice's A0.
Downside is that Bob may learn something about Alice<>Carol relationship being setup. Although Bob initiated it by sharing Alice's A0, so kinda knows it already.
This makes the database zero-trust because it is signed at rest
Interesting.
How does signing happens?
E.g., on change to IP address of A2 it signs and ifroms C0.
But then A2 can be behind a symmetric NAT, so it's IP is f(C0) - need C0 to tell A2 it's IP to C0.
Fortunately, a Diffie-Hellman computa-tion is fairly cheap — it involves only two modular exponen-tiations.
non-repudiation
Re-randomized TreeKEM
^
Briar [ 10] or Bridgefy [1 ]
Group membership changes andkey updates (for PCS) require effort proportional to the group size.
^
a consensus protocol could be used
Vector clocks
The downside of using hashes as IDs is that they requiremore space than other schemes. To avoid the storage cost ofexplicitly materialising all of the hashes, it would be possibleto design a compression scheme that recomputes hasheswhen necessary, and store only the information necessaryto perform this recomputation.
ting and proposing the same act— stating the most-preferred pointin the metric space. This provides a unified approach to making participantsequal as both voters and proposers
and,then, they are considered known by pk (Line 16).
This is optimistic.:)
Once the OK messagefrom a process in Pi is received, it can be considered againas a candidate to which to send a SPREAD message (movingit to Si)
Uh, were message be lost in transmission -> no OK will be received -> pi won't ever send any more messages to it. It can be SPREAD message loss or its reverse OK message loss.
Essentially, on each message loss there's one less link in the connection graph, until it gets fully disconnected.
That is, if we don't remove processes from P. E.g., when learning that it learned rumors that we sent (e.g., from others).
When a SPREAD action must be executed, one processpj ∈ Ni is randomly chosen (Line 12), and the set of rumorsknown by process pi but not assumed to be known by pj issent to this process pj in Line 14.
SAIDs MUST be encoded as a CESR [CESR] Primitive. As defined above, a CESR Primitive includes a pre-pended derivation code that encodes the cryptographic suite or algorithm used to generate the digest.
^
It can, therefore, serve as a universal store, isomor-phic to the PO-Log of pure operation-based CRDTs, allow-ing different CRDTs to be implemented
^
Anarchy is the total absence of governance, where no governmentnor laws exists. In this scenario individuals can interact peer-to-peer, butsince no coordination exists, it is impossible to scale up communication andproductivity.
Eh, what stops them to come to consensus regarding some topic?
Swiss folks interact peer-to-peer, passing laws.
This means that thecontroller might have to take measures, like revoking ij and kl.
Why so? They're not in the KEL anymore.
And those who learned them will accept superseeding recovery, so maliciously issued certificates out they go.
Here the payout is not triggered by the loss itself but by a measurable index, such as rainfall at a nearby weather station
^
Secure causal broadcast extendsatomic broadcast by encryption to guarantee a causal order among thedelivered messages
Due to lithium-ion batteries generating their own oxygen during thermal runaway, it is worth noting that lithium-ion battery fires or a burning lithium ion battery can be very difficult to control
lithium salts in the battery are self-oxidizing, which means that they can't be "starved out" like a traditional fire
verifiable LEI (vLEI) - the only universally standardized digital legal entity identifier
^
Who is who? Who owns whom? And who owns what?
^
Year-end Objective Prior to 2022
^
GLEIF is a supra-national not-for-profit organization headquartered in Basel, Switzerland
^
Established by the Financial Stability Board in June 2014
^
On June 26, 2024, Alexandre Kech took over from Stephan Wolf as CEO of GLEIF.
^
* Russian authorities have agreed not to participate in FSB meetings at present.
^
The FSF was first convened in April 1999 in Washington.
^
On 28 January 2013, the FSB established itself as a not-for-profit association under Swiss law with its seat in Basel, Switzerland.
^
In November 2008, G20 Leaders called for the FSF to enlarge its membership
^
established in April 2009 as the successor to the Financial Stability Forum (FSF)
^
It is often the case that Atoms need to wrap the functionality of existing python libraries, or that Atoms that represent abstract syntax trees need to be compiled down to bytecode.
This alone would not be enough to be reproducible.
One also needs to specify execution environment.
E.g., version of Scheme to be used.
The Nix/Guix way.
Link Node "edge label" Link Node "from vertex" Node "to vertex"
Link could contain Edges, right?
Overall, seems it'll be useful for Link to not care about the specific Node type (ConteptNode) for example.
As otherwise we'd need to make Link and others polymorphic.
Perhaps polymorphism can be defined once for an abstract Atom type, which can hold Edge or a typed Node.
E.g.,
Link
Atom
Concept Node "edge label"
Link
Atom
Concept Node "from vertex"
Atom
Numebic Node 42
Although, I guess a Type hierarchy can be used, defining that every type inherits Atom type.
Akin how in Java every class inherits Object.
Then it's possible to make Link expect Atoms.
However, if an atom is added to B that does not exist in A, then it will be in atomspace B only. If later it is added to A, then two independent copies shall exist: one in B and one in A. Its not quite clear if this is the 'right' thing to do; but defacto, this is what happens
Re-write refs to Atom X in B to point to the newly added same Atom X in A?
When an AtomSpace inherits from multiple contributors, the contents of that AtomSpace is the set-union of the contributing spaces.
The unique ID of a Node is it's string name
I thought things are content-addressed. Having a string name is strange.
One of the keys might hold the truthiness of this statement. Another key might hold its probability.
Aren't these two about the same? Where true is 1.
And say probability = 0.6 is a more fine-grained expression of truthiness.
This unimportant nitpick aside, can you annotate say truthiness = true with probability = 0.6?
(probability
(truthiness
(owns Jack computer)
true)
0.6)
( Joe , 3 . 5 ) , # T h i s i s n o t v a l i d JSON !
Umm, use an array? What are these ()?
this becomes a column-store
It's a way to compact. Row-based approach can also be used.
Although columnar is better.
This start-over style of key rotation may well be one of the main reasons that PGP's web-of-trust failed [WOT]. Without a universally verifiable revocation mechanism, then any rotation (revocation and replacement) assertions either explicit or implicit are mutually independent of each other. This lack of universal cryptographic verifiability of a rotation fosters ambiguity at any point in time as to the actual valid mapping between the identifier and its controlling keypair(s). In other words, for a given identifier, any or all assertions made by some set of CAs may be potentially valid
copy, or reference
What's the difference between "copy" and "reference"?
This enables an extremely beneficial property of TELs; that is, the verifiability of transaction events in the TEL persists in spite of changes to Key States in the sealing KEL. In other words, the verifiability of transaction events persists in spite of changes in the Key State
An Authentication Service (AS) that enables group members to authenticate the credentials presented by other group members.
This is weird. It's meant to be a p2p design, yet it relies on a CA to approve you. It's a single point of failure. May be corrupt.
If a member finds that another member's credential has expired, they may issue a Remove that removes that member.
That is strange. You need to periodically pop online to renew credentials or you're kicked out.
The Delivery Service cannot guarantee that application messages won't be dropped within the same epoch. To address this, applications can configure the maximum_forward_distance parameter of the SenderRatchetConfiguration. The configuration can be set as the sender_ratchet_configuration parameter of the MlsGroupCreateConfig
The Delivery Service cannot guarantee that application messages will arrive in order within the same epoch. To address this, applications can configure the out_of_order_tolerance parameter of the SenderRatchetConfiguration. The configuration can be set as the sender_ratchet_configuration parameter of the MlsGroupCreateConfig
The Delivery Service cannot guarantee that application messages from one epoch are sent before the beginning of the next epoch. To address this, applications can configure their groups to keep the necessary key material around for past epochs by setting the max_past_epochs field in the MlsGroupCreateConfig to the desired number of epochs
This is not reliable, no certain knowledge that any further messages won't come.
Capabilities per server: Is a given server participating in the room allowed to...
Servers should just relay messages.
When a client sends a message, the message is delivered to its provider's server using some provider-internal mechanism. If the provider is not the hub, then the server forwards the message to the hub for delivery.
http://example.com/didcomm
No need for transport security, given the payload is E2EE.
Mobile Agents Communicating via UDP
We recommend listening to the Zoom recording of the DUG special meeting
^
refinement to this approach, which reduces the amount ofinformation exchanged and the size of the tables, is to have the DBMPsexchange only the oldest of the entries in the first table (oftimestamps of last modifications received from other DBMPs).
Resembles delta-based state CRDTs optimization technique, where only latest vals are broadcast.
(T1,D1)>(T2,D2) <=> (T1>T2) or (T1=T2 and D1>D2)
Resembles tie-breaking based on origin ID, seen in systems that use other T (e.g., Lamport Clock).
In [2], Berners-Lee and Connolly proposed Delta, an ap-proach in which the RDF-Graphs differences are calculatedon their serialized forms
This resembles the way Git works, we have snapshots and deltas are calculated out of them.
Ironically, that made Git use deltas more, not less.
DAG-based consensus protocol are all the rage
^
A Grassroots Architecture for the Digital Realm.
^
virtual blockchains
The master key may also be used to sign other items such as the backup key
Given her master key is compromised (and that is the case when she'd like to rotate) nothing stops the compromised to issue and sign a new backup key.
Better: use pre-rotation of KERI.
a master key (MSK) that serves as the user’s identity in cross-signing and signs their other cross-signing keys
Is a point of failure / weakest link in this chain - compomise of one key is enough to compromise Alice's identity.
Also, requires it to be replicated across her divecise, if she wishes to add new device from any device.
In addition to connectivity, there are other Matrix-centric problems to be solved. In a world where each device is potentially running its own homeserver, we will need a new approach for handling user identities
Since federation within a Matrix room is effectively full-mesh, you need to be able to exchange data with all servers that are participating in a given room directly
As we discussed in #matrix-spec, since "rooms" are so much more than "chat rooms," and are really a DAG of events
from the perspective of the homeserver which created the event
Homeservers create events, not users.
All API endpoints within the specification are versioned individually. This means that /v3/sync (for example) can get deprecated in favour of /v4/sync without affecting /v3/profile at all. A server supporting /v4/sync would keep serving /v3/profile as it always has
It's cool, I guess. But then leaves one wonder, are they compatible? How to tell? There should be a kind of manifest then that maps v4 to "playing well together" granular vs.
For example, if /test were to be introduced in v1.1 and deprecated in v1.2, then it can be removed in v1.3.
That's.. not intuitive for those familiar with semver.
Like, bump it to 2.0 instead. It's a breaking change. Everybody will get it. What's the point of the second digit if it guarantees "maybe nothing will be broken" - tell it explicity, is it or is it not.
vX.Y
v bit makes it non-semver.
Better: semver. It's widely known. You can leave Z in X.Y.Z as 0.
Users may publish arbitrary key/value data associated with their account
This is personal information one may wish to chose who gets access to.
Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs
Better: linke from 3rd party to Matrix.
E.g., by adding on Twitter link to Matrix ID.
Each state event updates the value of a given key.
I hope it's a CRDT update.
file transfers
Better would be to include files as is. Use hash of it in an event. Download from whoever has it, the IPFS way. Only between friends
Every event graph has a single root event with no parent
Weird. That means one user must start a topic. Whereas a topic like "Obama" could be started by multiple folks, not knowing about each other, later on discovering and interconnecting their reasoning, if they so wish.
Events exchanged in the context of a room are stored in a directed acyclic graph (DAG) called an “event graph”.
Well, better call it "event DAG" then?
Or, "event hash-DAG" / "Merkle-DAG".
type values MUST be uniquely globally namespaced following Java’s package naming conventions, e.g. com.example.myapp.event
We're in the Web. Better: URIs.
In a mobile client, it might be acceptable to reuse the device if a login session expires, provided the user is the same
Yeah, we wouldn't have this problem if agent's key been authorized.
each device gets its own copy of the decryption keys
Whoa! Sharing the one and only private key is.. sub-optimal.
each of which would be its own device
Better call them "agents". "An app is a device" sounds incorrect.
signing the message in the context of the graph for integrity
That's weird. User's not in chare of creating an event (as user-generated event is not a complete event in Matrix model, it lacks causal history).
Relying for creation of an event on a server means you need to be online in order to use apps.
Better: let user's device be enough, so user can create events offline, sync it later. Server is dumb - just relaying it to user's friends.
Room data is replicated across all of the homeservers whose users are participating in a given room
and shares data with the wider Matrix ecosystem by synchronising communication history with other homeservers and their clients
That's a con. There's no need to sync globe-wide, creating a giant ledger. You have a set of peers that you want to share your stuff with (friends), leave it at that.
Use of 3rd Party IDs (3PIDs) such as email addresses, phone numbers, Facebook accounts to authenticate, identify and discover users on Matrix
Good stuff. I.e., associate existing accs.
Managing user accounts (registration, login, logout)
Better: always log in with a server, unless you choose to migrate.
Extensible user profile management (avatars, display names, etc)
Better: let peers have personal profiles of their friends.
Like you do with your contacts on phone. You know their id (phon number), you give it a name, assign a pic. It's up to you.
Extensible user management (inviting, joining, leaving, kicking, banning) mediated by a power-level based user privilege system
Additionally: community-based management, ban polls.
Alternative: per-user configuration of access. Let rooms be topics on which peers discuss. A friend can see what he's friends and foafs are saying.
REST
That's a standard - good for devs. Yet it's grotesque.
causal order does not refer to the actual ‘real’ causality of the messages
Further, we conjecture that the only non-trivial Byzantine-tolerantCRDT design is a grow-only HashDAG as it is done in the Matrix Event Graph
So this
"A real solution to distributing state has to involve direct messaging with an offline mechanism."
MERKLE-CLOCKS
ipfs-log24 is, to our knowledge, the first existinginstance of a Merkle-CRDT as described here
^
Chronofold and co-structures
^
Figure 9.13. Delegated Establishment Event.
Why there is no perms in the Delegating Event and are in Delegated Event? I'd expect it to be the other way around.
Custodial Key Management
Using seals, the delega-tor’s and delegate’s event streams are cross linked together
applications may benefit from other delegative properties such as the ability to attenuatecontrol authority
how so?
A nested set of delegation levels may be used to form a dele-gation chain or a delegation tree
In some critical interactions, however, the trade-off between convenience and security madeby reusing signing keys for multiple interaction events may not be acceptable. In this case, amore secure approach is to combine an interaction event with a rotation event by adding a pay-load data structure to the rotation event.
To elaborate, a successful live exploit must compromise the unexposed next set of private keysfrom the public-keys declared in the latest rotation
Figure 11.5. KERL for a Recovery Rotation Event.
Rotation event as authorization of below events.
N ≥ 2F + 1
This case is prevented when the inter-section subset of any two agreement sets is large enough to include at least one honest witness
Yup, that's why we have M > (n+f)/2
Which for f = 1/3n, (3/3+1/3)/2 = (4/3)/2 = 2/3
When sufficient agreement may occur on more than one version of an event then a valida-tor may not be able to determine which version is authoritative in order to either to hold the con-troller accountable or to reconcile that event with respect to other validators
Crazy idea: rotate key after each interaction event.
Thus an interaction is deemed valid only if the key's been rotated. Although what's the use if keys are non-extractable in a HSM. Their security = security of the pre-rotated key. I.e., given no hardware attack vectors, decive gets stolen - both approaches are compomised.
but where the witnesses are not under its control such that the a validator or originalcontroller may nonetheless trust that there may be no more that F faulty witnesses
I.e., witnesses may be unaffiliated, providing trust.
The controller is responsible to promulgate a mutually consistent set of receipts, i.e. a suffi-cient agreement of size M ≥ M C .
Why? Witnesses can gossip with each other acks about events they learned from the controller.
As mentioned further.
Without a threshold a validator may choose to hold a controller ac-countable upon any evidence of duplicity which may make the service fragile in the presence ofany degree of such faulty behavior
Suppose instead that N = 3F + 1 , then a correctagreement is guaranteed as before but the agreement will have 2F + 1 nodes (quorum size) anddespite some F of those 2F + 1nodes becoming unresponsive, the remaining F + 1 honest andresponsive nodes will be able to propagate that correct safe agreement to the next round
The reason behind N=3F+1, is that F nodes may behave duplicitly. So we need ((N-F) / 2) + 1 to have it safe.
But there is no guarantee that the nodes in agreement (quorum) will knowthey came to agreement in a subsequent round because as many as F of the nodes in agreementin a given round may subsequently become unresponsive in the next round
But we have f+1 for agreemend, so it will be live.
This may be called a multi-controller or collec-
An escrow cache of unverified out-of-order event provides an opportunity for malicious at-tackers to send forged event that may fill up the cache as a type of denial of service attack. Forthis reason escrow caches are typically FIFO (first-in-first-out) where older events are flushed tomake room for newer events.
This may misfire, when there's a ton of valid events to sync, whose amount is greater than the cache limit.
May happen when adding a new witness, requiring to sync the entire history. (do we need to provide it the entire history though? only the last not-yet-verified events are of interest for the controller to be signed by the witness)
UTP
UDP?
Event escrow isan optional implementation specific configurable capability of controllers and witnesses imple-mentations
Each time the controller connects to awitness to send new events and collect the new event receipts, it also sends the receipts it has re-ceived so far from other witnesses
When network bandwidth is less constrained then a gossip proto-col might provide full dissemination with lower latency than a round robin protocol
When a rotation amends the witnesses it includes the new tally, the setof pruned (removed) witnesses and the set of newly grafted (added) witnesses. This is shownbelow.
where K ≤ L
And K > L / 2, I guess. Otherwise two blocks can be authZ in a fork.
The specific details of this recovery are explained later (see Section 11.6). In gener-al, the witnessing policy is that the first seen version of an event always wins, that is, the firstverified version is witnessed (signed, stored, acknowledged and maybe disseminated) and allother versions are discarded
Seems to harm convergence
the message payload inside an IP packet includes aunique identifier provided by the identity system that is exclusive to the sender of the packet
Including identifier in message, coupled with key-pair->identifier mapping is meant to give authenticity - that message came from the identifier.
Problem 1: keypair will be eventually revoked, how to convey authenticity of messages before revokation and not after?
Solution 1.1: Issue event with logical revokation time. I.e., revocation is issued on Fri, but meant to take place logically on Thu.
Then, messages received on Fri and forward, signed by that key-pair, will be deemed not authentic.
Solution 1.2: Use multiple signatures to prove authenticity.
Then, even if one gets revoked - authenticity holds.
Con: metadata overhead, need for keypair agents to be connected, higher delay - meh.
Is there value to include identifier, given recepient still needs to resolve mapping keypair->identifier and keypair can be binded to one identifier only.
Yes, identifier hints how to resolve it.
Also more recently theTrusted Computing Group (TCG) uses the term “implicit identity” and “embedded certificateauthority” to describe the process whereby device identifiers are automatically generated by theassociated computing device [143]
Using a DID as an endpoint
Can subsequent next refer to a DID?
An identity is also a topic to subscribe to (i.e. the ledger is based on subscription)
ID as pubsub topic.
In contrast, a relay is an entity that passes along encrypted messages without understanding or decrypting them. It's focused on network routing only.
Mediator is a "smart" relay, in that it knows the adressee and can relay with that in mind.
Relay, on the other hand, does not know the destination, it works deterministicly. Iff that relay would always route messages to Bob, then Alice doesn't need to tell anything specific to the relay.
Two Dimensions
Therefore, there is no unified absolute ordering of all messages within a thread--but there is an ordering of all messages emitted by a each participant
Again, the discloser can retain the ‘Admit’ message as non-repudiable digital proof that the disclosee has admitted the disclosure of the ACDC
What stops disclosee to not send the "Admit"? Thus being repudiable to "I haven't received the promised and agreed upon info".
For a given AID, Duplicity refers to the existence of two or more versions of inconsistent instances of a KEL.
Events in the TEL are sealed (anchored) in a Key Event Log (KEL) using seals.
Every TEL event gets anchored?
r can provide an API where transaction events or their seal references and their KEL seal references can be looked up by the SAID of the ACDC associated with the transaction event
I guess lookup is meant to be specified, and not ad-hoc. So software can do it without human (programmer) guidance.
NOT
This serves to convey different semantics than the above fields. I'd expect it to be in a different field.
When an Edge block does not include a SAID, d field, then the node, n field must appear as the first field in the block.
Strange. All we need is d. Introducing n makes it not uniform. I'd expect there to be d solely, replaced at run-time with it's content.
Notable is the fact that no top-level type fields exist in an ACDC. This is because the Schema, s, field itself is the type field for the ACDC and its parts
where each Edge block is a leaf of a branch
Rather, "where each Edge block is a leaf or a branch".
Without the entropy provided the UUID, u, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the Schema of the block using a rainbow or dictionary attack on the set of field values allowed by the Schema
I.e., knowing a schema makes it possible to derive content from its hash.
It’s just a chain of custody
a little bit about consensus algorithms
but I also have one: a verifiable data tree, not just a chain. So in my view, a verifiable data tree is the solution, not a shared blockchain
blockchains are too expensive, too complex, too hard to scale, and too slow-moving in their governance
Open identity systems should stay agnostic to all silos and blockchains
I.e., identity system should be ledger-agnostic.
consensus network called KERI
Any selective disclosure is potentially ineffective unless per-formed within the confines of a contractually protected disclosure that imposes an incentive onthe disclosee (verifier) to protect that disclosure (counter-incentive against the exploitation ofthat discloser).
that a given DID is guarded by M-of-N signature policies, for example
This makes the DID functionally equivalent to a did:key value, and visually similar, except that a peer DID will have the numeric algorithm as a prefix, before the multibase encoded, multicodec-encoded public key
Then why have it?
In order to do this, a form of network-wide election takes place, where the node with the numerically highest ed25519 public key will win
Eh, that doesn't seem fair. What stops one generating keypairs until he gets a decently high one, cheating his chances?
Even though the Pinecone address space is considered to be global in scope, it is important to note that there is no true “single” Pinecone network. It is possible for multiple disjoint and disconnected Pinecone network segments to exist
In some cases, source addresses could be sealed/encrypted, although this is not implemented today
implement a better federation routing algorithm than full-mesh routing
Power DAG
yggdrasil
but limiting the conference to 7 or 8 participants given all the duplication of the sent video required. In Element Call Beta 2, end-to-end encryption was enabled; easy, given it’s just a set of 1:1 calls.
I imagine having to transmit stuff to every peer would not work well for low-bandwidth devices.
Also, complete connectivity graph is a LOT of connections.
Additionally, given one channel fails - recipient doesn't see content, while others do. (they could have broadcasted it, hey!)
Also, won't scale for streaming.
instead it’s more of a QoSed incremental sync
So if the network roundtrip time to your server is even 100ms, and Sliding Sync is operating infinitely quickly, you’re still going to end up showing a placeholders for a few frames
What stops loading context around the window?
Better off, start from windows position and sync everytihng from that priority.
I.e., prioritize what gets replicated by how user's acting.
Faster Joins (lazy-loading room state when your server joins a room)
The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate
111,873,374 matrix IDs on the public network, spanning 17,289,201 rooms, spread over 64,256 servers