This module is still in development, see #217. XEP-0115
Verification
If a user's client uses an invalid "ver" hash or always returns nonsense to requests to explain it, they're probably going to repeatedly get requests because nothing else can be done...
Storage
It should be optional to cache either of these in storage, mod_pep will require features info but nothing else would currently use caps-identities and it could be ignored for now. Creation time and last use time might be useful, particularly for deleting old data.
There needs to be some way to indicate that a given "ver" hash has no features or identities... perhaps a NULL data entry? Some DBs won't allow a primary key field to have NULL values.
caps-features
| ver | text | Entity Capabilities "ver" hash |
| hash | text | "SHA-1" |
| object-sequence | bigint | ? |
| feature | text | Feature values (repeat row as required) |
PK: ver + hash + feature
caps-identities
| ver | text | Entity Capabilities "ver" hash |
| hash | text | "SHA-1" |
| object-sequence | bigint | ? |
| category | text | Identity category, i.e. "client" |
| type | text | Identity type, i.e. "pc" |
| lang | text | Identity lang, i.e. "en" |
| name | text | Identity name, i.e. "Psi" |
PK: ver + hash + category + type + lang + name
