Christopher Joel
Christopher Joel
In #420 we have introduced a unified method for signature verification for spheres. However, it does not currently take revocations into account when verifying the signature. Each link in the...
We've encountered at least one case where the local block storage becomes corrupted and is apparently unrecoverable: https://github.com/subconsciousnetwork/subconscious/issues/693 A blunt solution that will likely "fix" this for the majority of...
Currently we make wide use of ed25519 keys (via [`ed25519-zebra`](https://crates.io/crates/ed25519-zebra)), except on the web where we use RSASSA-PKCS1-v1_5 (via the [Web Crypto API](https://w3c.github.io/webcrypto/)). ed25519 has various virtues (small public key...
To mitigate abuse, we should probably cap the spread between revisions to some finite value that is permissive of 99% of usage. Maybe somewhere in the ballpark of 1~10k revisions....
Currently we do some diligence to make sure that spheres most likely have a causal order when replicating them incrementally (that is, by replicating all the version deltas between two...
As of #253 , we will have end-to-end name publishing and resolving. However, only the name resolvers currently do any validation of name records. Name records must also be validated...
Consider a sphere traversal from spheres `A -> B -> C`. For such a traversal, we currently look in sphere A's address book for the last known link record published...
Currently we check most write operations to verify that the author has read-write access to the sphere context before proceeding. Although there is no danger that the author can create...
Now that we can express a never-expiring UCAN via `None` for `exp`, the `UcanBuilder::with_expiration` method should accept `Option` so that a user can express a never expiring with `builder.with_expiration(None)`.
Part of #11 https://github.com/ucan-wg/spec#42-own