Closed cygnusv closed 3 years ago
Of course, this would imply that grant specification in character control changes from:
__grant = (('bob_encrypting_key', 'bob_verifying_key', 'm', 'n', 'label', 'expiration'), # In
('treasure_map', 'policy_encrypting_key', 'alice_verifying_key')) # Out
to
__grant = (('bobs_card', 'm', 'n', 'label', 'expiration'), # In
('treasure_map', 'policy_encrypting_key', 'alice_verifying_key')) # Out
And now that I think of, we can do something very similar with the public output of grant
(i.e., policy_encrypting_key
and alice_verifying_key
). Assuming we have something like a "policy card" encompassing both keys, then the specification of grant can be:
__grant = (('bobs_card', 'm', 'n', 'label', 'expiration'), # In
('treasure_map', 'policy_card')) # Out
This is a great idea and something I've been wanting to bring up. I think this card proposal is awesome, but I also want to think about other less dated abstractions.
Great issue, @cygnusv
Yeah, this is good stuff. I think "card" is fun. How universal is the concept of a business card? My inclination is that most people will get it right away, but I'm also from an age group and country that has put up with business cards for a long time (and is pretty much ready to give them up in my estimation in their physical form, but they still make a good metaphor).
One concern I have is that we may end up with an additional layer of abstraction wherein each Character contributes different things to its card - do we want that? IE, are we going to have things like BobCard
and EnricoCard
?
One concern I have is that we may end up with an additional layer of abstraction wherein each Character contributes different things to its card - do we want that? IE, are we going to have things like
BobCard
andEnricoCard
?
Yes, I think we want that. You can see it from a different angle: from the perspective of our users, what's important is that Characters sometimes need to share certain relevant information about themselves with others, in this case in the form of cards. We, as developers, will include different information depending on the circumstances but that's something that's not necessarily interesting for nucypher users.
I propose the following:
Thumbs up anyone?
I like the card metaphor in that it would make it clear what information is allowed to be public. Presumably, only public information would be included in the card and subsequently divulged - abstracting that adds a layer of implementation complexity but also a layer of simplicity from the user perspective.
Keeping up with a lot of our fun narratives that we use. Allow me to introduce the concept of a "Credstick".
Originally, this concept is from Shadowrun, a Cyberpunk RPG. Essentially, the Credstick acts as a means of transacting. In fact very similar to a hardware wallet for typical cryptocurrencies. Many only remember it as a wallet, but it was also used as a means of presenting identification -- a lot like how cryptocurrency wallets are being used now.
I propose that Card
be dropped in favor of Credstick
. I think it's fun and adventurous and a nice cyberpunk metaphor that is quite flexible for how we may need to use it.
How universal is the concept of a business card? My inclination is that most people will get it right away, but I'm also from an age group and country that has put up with business cards for a long time (and is pretty much ready to give them up in my estimation in their physical form, but they still make a good metaphor).
Well, if the concern was "card" not being universal enough, I think "credstick" is way inferior under this criteria. I mean, I don't even know what it is. Only Cyberpunk RPG gamers will understand it without an explanation. That defeats completely the purpose of the metaphor; we may as well make up a new name.
The great thing of most (all?) of our metaphors is that they are immediately obvious (capsule, treasure map, stamp, etc.). I strongly think we should continue this tradition.
OK, I think I got it....NAME TAGS!
– Name tags! Name tags! What kind of an idiot thinks anybody would be interested in an idea like that. – I don't think it's so bad. People should wear name tags. Everyone would be a lot friendlier. "Hello, Sam." "How are you doing, Joe?"
Another idea: MULTIPASS
(I've been wanting to use stuff from "The fifth element" namespace for a while 😛)
@cygnusv I like the idea of NAME TAGS or also NAME BADGES
Hmmm, not really a fan of the name badge because it lacks the nuance of authority.
The one thing I would add is maybe naming this internally as "public-card" or something like that, so that it is clear as @derekpierre mentions. Or maybe just "card" is fine, but would we ever want to have a "private-card"?
When granting, Alice currently* needs Bob's signing key and encrypting key, and this is explicitly required by the grant method and all its wrappers (e.g., character control endpoints). This means that users are exposed to this low-level design decision, and from an UX perspective, they shouldn't be. They also have been a source of recurrent problems in the past, as shown by many questions in #general about failed joins and retrievals.
I propose to abstract this information in the concept of card (like business cards). In principle, it can be a helper class whose bytes representation is something like this:
The workflow can be as follows:
I want to work on this, but I preferred to ask your opinion before. Of course, and as usual, there's a potential naming discussion here (I'm hearing @jmyles in my head giving a speech about the ontological nature of cards and whether it's a good metaphor here). I think there's room for better metaphors.
(*) I said "currenty" because I think the whole HRAC design is weird and confusing, and I think we can come up with something better. The good thing of the card approach is that we can abstract this from the user, and even if we later change what's the information from Bob required for Alice to grant, users will still continue issuing and receiving cards.