amark on manhattan
hmm, IDK if we should support t… (compare)
mmalmi on master
Update app.json (compare)
mmalmi on master
Add PEERS env variable to app.j… (compare)
amark on manhattan
easy to debug & fix thanks to @… (compare)
rogowski on manhattan
Update common.js Tests updated… (compare)
amark on manhattan
all caught up!!! Now update tes… (compare)
amark on manhattan
amazing map discovery + don't c… onto next test... (compare)
amark on master
Don't prune devDependencies on … (compare)
user.pair()
raises a deprecation warning. What whould I be using instead? I'm doing this and it's working great: // runs in browser A
const s2 = async bobEpub => {
const alice = user.pair();
if (typeof user.is !== "object") {
throw new TypeError("user.is not an object");
}
if (typeof bobEpub !== "string") {
throw new TypeError("bobEpub is not an string");
}
const sec = await SEA.secret(bobEpub, alice);
const enc = await SEA.encrypt("secret message", sec);
console.log(enc);
};
// runs in browser B
const s3 = async (encodedMsg, aliceEpub) => {
const bob = user.pair();
const sec = await SEA.secret(aliceEpub, bob);
const msg = await SEA.decrypt(encodedMsg, sec);
console.log(msg); // "secret message"
};
user._.sea
Hmm... the problem with trying to let developers drive changes in a bucket from another bucket, is the potential to create event loops. It would be great if the framework would provide a solution to detect these before run-time but that's really hard to do. We could have a system where changes in bucketA sometimes drive bucketB, and bucketB sometimes drives bucketA, and there's no event loop. Like this: bucketA.state.a -> bucketB.state.a
, and bucketB.state.b -> bucketA.state.b
, and this would be okay, but we wouldn't be able to know which properties will be changed by which reducers. Even if we try to parse the reducer logic, it could have conditions, like
if (thing) {
return { propA: false };
} else {
return { propB: false };
}
So dependent on thing
, we either change propA
or we change propB
. I think there's no way to evaluate the results other than fuzzing, and that's hard.
I think redux / flux address this by requiring only 1 store, which I think will be the right direction. That would mean we can only have 1 bucket, which means buckets will need support for multiple data structures somehow.
oi.
Here's a thought: What if we started going around to various self-hostable, open-source apps and just started submitting PRs where the user logins are replaced with SEA instead of their existing centralized database logins lol
Make a best practices guide for swapping user logins to SEA and do it guerrilla style lol