-
Notifications
You must be signed in to change notification settings - Fork 27
Sending a request for authorization
Two paths to send requests for authorization.
-
Add contact to contact list (Keyhotee ID or public key). On the toolbar of the window contact, Send and Chat options disabled, enabled Request authorization. Selecting Request authorization triggers filled message window requesting authorization. Keyhotee ID or Public Key, TextEdit with greeting message and button Send.
-
Main menu -> Contact -> Request authorization Calls messages window requesting authorization with greeting message. Required to provide Keyhotee ID or Public Key. After sending the message we force the addition of a Keyhotee ID or Public key to the address book. If the recipient is already in address book, the contact will be open.
Authorization response
Answer authorization appears like a chat message in the left panel. Click to open authenticated contact.
void application::send_contact_request( const fc::ecc::public_key& to, const fc::ecc::private_key& from )- not implemented, we plan to implement analogical like chat message
Request
struct private_contact_request_message {
std::string from_name; is this full name? DLN: I think this should be Full Name + keyhoteeId or public key if no keyhoteeId. Full Name is whatever user sets, but keyhoteeId and public key can't be spoofed, so it would increase security somewhat.
channel_id from_channel; DLN: I suppose this is channel we're sending this request from
channel_proto::peer_proto?
Answer
struct private_contact_auth_messag
std::string auth_text; answer only as string? we should parse this string?
fc::uint128 min_work; ///< how much work is required to contact this individual ???
fc::time_point_sec expires; who sets this parameter?
std::vector<network::channel_id> listen_channels; this is a list of channels this person listens on. It informs requestor of channels that can be used to contact this person.
fc::optional<fc::ecc::private_key> broadcast_key; ???
Contact Authorization
Eventually there will be two purposes for contact authorization: a) allowing two users to do "direct connect" instant message and email communication without broadcasting to the general peer-to-peer network and b) allowing exchange of extended public keys that will allow generation of a sequence of public keys. The primary purpose of generating this sequence of keys is to allow block chain transactions to occur between the two users with enhanced privacy. For example, if I send some BTC to friend A, then send more BTC to friend A later, the second transaction will automatically be sent to a different public key that I know is owned by A. There is a specialized API for performing an authorization request, although I don't know how much of it is yet implemented.
Note that from the above, this contact authorization doesn't necessarily have anything to do with communications blocking, but I think we should consider adding an option that allows an identity to refuse communications from anyone who's not been authorized by that identity. This option would require modifying the identity structure, however, so let's wait till database versioning is complete before we add that field.
Sending Contacts
Sending contacts to another user will be done via a mail message that contains the contacts. The contacts will be stored off in a special format that the other side can recognize as "importable" data. I think that we should probably use the JSON serialization code in fc to serialize the contact records into text. On the receiving side, we can then try to deserialize the mail message and enable an "import" option if the mail message contains an importable record type. This would leave room for allowing other types of records to be imported in the future. This will also give us a simple way to export the data into a regular ASCII file.
No information, with identity was used to authorize the contact
The address book is one for the profile, and identity can be several. Missing information with identity was used to authorize the contact