I created this temporary group chat in order to provide a place that we can post a message among the four of us as needed.
I have messaged each of you individually in the last 18 hours or so concerning an idea that came up for me last night, as I was designing . .
Gyuri has gotten me thinking about the way that Chitchatter uses cryptography to provide secure communication, but does not provide any means of carrying those credentials between experiences or web contexts.
Gyuri has expressed clearly to me that Basic Authentication is not needed, and that I should expand my mind essentially . . think more holistically. I do not entirely agree that Basic Authentication (standard HTTP practices) does not have its place or that it is not important. I want Situs to meet and then exceed expectations set by the conventional web. Therefore implementing Basic Auth and not having to "reinvent the wheel" is just following through with the expectations set by the conventional web . . now let's follow Gyuri's inspirational lead, and think further ahead, before making a settlement.
Gyuri did get me to thinking. He plants these ideas in my mind . . like weeds! They grow and spread without any attendance, even when I try to stamp them out at first . . here he goes again, inspiring me, cultivating.
I do not wish to go on and on here . . He got me thinking about how to implement public-private key cryptography in a way that will be able to travel between web experiences and contexts. The exact same sort of cryptography that drives (and would be interoperable with) Chitchatter and that whole ecosystem but we need a little engine that provides a secure context for doing:
1.) Proving who you are (and what you have created) by:
a. sharing public key
b. protecting a private key
c. signing authored docs with private key (verifiable with public key)
2.) Verifying the authenticity of others:
d. verifying signed documents with associated public key
3.) Addressing trusted peers:
e. Send encrypted message/file/stream to peer,
(peer's public key locks the data; peer's private key unlocks the data)
4.) Recieving messages as Adressee:
f. Receive encrypted message locked with one's public key;
(Must ensure that the peer is trust-worthy! by association?)
h. Decrypt private messages with private key.
There is more to it . . must consider deeply how association and trust works in these systems . . all kinds of questions, like Addressing encrypted data unlockable by multiple parties . . lots of questions, which have been answered before by cryptographers who have left instructions and tools.
But this is the basic idea. The browser disallows doing anything with private keys . . shared between browser contexts, because another site could just steal your identity. Now, I can't think of a reason that Brave has not backed this into their browser!!!! That is the optimal place, and I am sure they have thought about it deeply, not sure who is stopping them. Because it has been years, and nobody has implemented this, I think I see a rudimentary yet effective solution: provide secure context on device exposed as API like IPFS does.
I would like to call a meeting or simply to append this question as an agenda item.
I would like your feedback about this idea, which I have introduced to each of you as Hiya! —BYOID. See: it's cute, and this can resonate. I have thought of a way to make it resonate more powerfully . .
If the tool does not provide a visceral service, that serves an obvious purpose, then most people just won't use it period —only tech enthusiasts will get around to using it, and we all know that what keeps us stuck on social platforms is the community. I don't think BYOID will catch on by itself,
if it is only a daemon service running in the background. It needs to be included as part of a very useful system, and I would love for us to plan to envision that together . .
IndyWeb 🦅 (alpha team)