Contents
|
1 Identity
An identity is a linkable entity, typically a person entity, but a service identity may be linkable, too.
A UNI is used to address an identity and the home server is where a user's own identity resides.
2 Jobs
This is a tentative list of jobs to be handled by the identification (we often just refer to it as the UNI because it is shorter to type).
Fippo & el think an identification MUST NOT handle any additional methods, but must pass them to linked clients.
Some questions come to mind:
- how does the MMP part of a message look like when it is passed to a client?? What happens to _target, _source etc..? _context remains the same.
2.1 Friendships
I recommend replacing those by normal subscription methods used by all channels (as is suggested in the Subscription document, but not implemented yet)...
- _request_friendship
- _notice_friendship_established
2.2 Presence
Presence is not like subscription or joining groups.
2.3 Linking of clients/locations
An identification may provide resolution of UNLs and UNRs into UNIs and back, so higher level processing knows who they are dealing with, no matter which agent operated on this person's behalf. In this case it will provide either forwarding or redirection of messages to locations that successfully linked to it. See below on same page.
2.4 Storage
2.5 Authentication
- _request_authentication
- _notice_authentication
2.6 Trustiness
- _request_trustiness
- _notice_trustiness
2.7 Behaviour when no client is linked
2.7.1 Store messages
Methods of the _message family should be stored in absence of a client.
2.7.2 Throw errors for unknown requests
2.8 Linking to an Identity
The main purpose for a location (usually a user's client) to be on the PSYC network is to get linked to one or several identities (usually a person entity) in order to be able to execute commands or send messages on its behalf. The location application was probably given a UNI, so it needs to resolve that uniform in order to create a circuit to it, then negotiate a link to it, which is done by sending a _request_link packet to it.
The packet has to be _targeted at the UNI and optionally provide a UNL as _source. This is an example:
| :_target psyc://fi.ve.symlynx.com/~fippo :_tag 284232 _request_link |
When (after authentication) the link could be established a _notice_link packet is unicast from the identity to the location The _source variable must contain the UNI (the identity's uniform) and the _target variable the UNL (the location's uniform):
| :_source psyc://fi.ve.symlynx.com/~fippo :_target psyc://ente.aquarium:-32872 :_tag_relay 284232 _notice_link |
NOTE: This unicast may in future be replaced by a multicast to a context of links including the new one. In that case it will be a method derivate of _notice_context_enter like _notice_context_enter_link. Even the _request_link may become an alias or be replaced by a _request_enter to the context of links allowing for any authentication method supported by contexts to be applied to links.
2.9 Authentication
2.9.1 Plain password authentication
If you don't care that your password is transmitted in plain text you can just set the _password variable when sending the _request_link packet:
| :_target psyc://fi.ve.symlynx.com/~fippo :_tag 284232 :_password godsecretXX332 _request_link |
2.9.2 Hash based authentication
In order for the identity to check whether the _source of the _request_link is allowed to link it sends a _query_password packet to the _source as reply to the _request_link packet. The reply contains a _nonce variable that is used to do hash-based authentication as follows.
Such a _query_password packet may look like this:
| :_source psyc://fi.ve.symlynx.com/~fippo :_target psyc://ente.aquarium:-32872 :_tag_relay 284232 :_available_hashes |sha1|md5 :_nonce 6eaa3554 _query_password Please show identification. |
You should proceed by sending a _request_link again with the variable _method set to the hash function used and _password containing the hex encoded hash of the nonce and the password concationation.
The hash function to use can be chosen from the list in _available_hashes, which is one of these:
- sha1 - SHA1 hash algorithm
- md5 - MD5 hash algorithm
Such a packet may look like this:
| :_source psyc://ente.aquarium:-32872 :_target psyc://fi.ve.symlynx.com/~fippo :_tag 984383 :_method sha1 :_password 68fe60d9b3989848c39842bb3038f515bf7979d3 _request_link |
The password field in the reply contains sha1(nonce + password) = sha1('6eaa3554xfippox') = '68fe60d9b3989848c39842bb3038f515bf7979d3'. The + operator in this case is intended as string concatenation. Note that you don't need to resend the _nonce.
If the password was correct you will receive a _notice_link as described earlier. But if the password was wrong a _error_invalid_password packet is generated as response, which looks similar to this:
| :_source psyc://fi.ve.symlynx.com/~fippo :_target psyc://ente.aquarium:-32872 :_tag_relay 984383 _error_invalid_password |
2.10 Unlinking from a Person Entity
If you want to unlink from the person entity again send a packet with _request_unlink method. The reply to that packet must be a _notice_unlink packet.
| :_tag 2 _request_unlink |
The person entity then has to reply:
| :_tag_reply 2 _notice_unlink |
3 Linking a _service of a UNI
You can make specialized applications that link in parallel to a main client by providing a _service at linking time. _service is supposed to contain a method substring match. All events arriving at UNI which match this service will then be forwarded to you. Examples are _service _mail or _news or _update.
Example for a service link operation:
. =_target psyc://example.org/~me :_password bofh :_service _news _request_link .
4 Linking multiple clients to a UNI
As you have seen above by means of _service you can already link several clients or client-like applications to one identity. The difference is only, the primary client gets all messages, the other clients only get what is filtered for them or otherwise directed to them. This should be enough, but should you want to allow for more than one catch-all client we only need to make a small change in psyced:person.c to allow for that. ppp probably already supports multiple clients, but it doesn't provide _service instead.