Members and accounts

Members / accounts / currencies
There needs to be a flexible approach to members and accounts. Accounts are considered the most fundamental.

• Every identified person will be signed up to the system as a member
• There will be a many to many relationship between accounts and members..
• Each account will be associated with a member or members, a registered address, and will be classified as an individual or an organization account. Matthew says: what is the difference to the system between an individual and organisational account? tax breaks? limited liability?
• Each account will be associated with a subset of the available currencies, some of which may be open only to those who meet specific eligibility criteria.
• Under most circumstances, there will be one account per member.
• Offers / wants / adverts will belong to a specific account.
• While logged on, users will be able to switch between accounts, but would not typically be expected to administer both on the same page.

Identity means how a person is known to the system; primarily what data is held on that person. It does not cover what data can be seen by other people. The issue is complicated by changing identities, attempts at fraud. Anything else? - People occupying different roles.

• All of this information will be visible and editable by the members themselves.
• In addition, but handled elsewhere in this document: their role in the system, their balance and trading history, messages posted, internal mails sent, complaints, 'quality of trade' feedback from other members, who their buddies are, their offers and wants, the categories in which they operate, etc.

Member information
"Each member is represented by a data set including (at least) the following fields:

• name,surname

• forenames
• username
• member type [individual|organization]
• organization type [non-for-profit|for-profit|social_enterprise]
• date of birth
• sex
• NI number*
• preferred language**
• access requirements** [visually-impaired|hearing-impaired]
• ethnic origin**
• occupation**
• employment status**
• home|business address (street, village/district, county/borough, postcode)
• telephone (landline, mobile, VoIP)
• email

Some of these (**) are needed only for statistical/funding purposes and some others (*) may be needed only for membership of particular subsystems.

Only some of this information will be displayed to other members by defaults, although members will have the option to display certain fields (**).
Each member will have a unique username (or "nickname") - typically a variation of their own name of business name. (Since these are unique, they can only be issued on a first-come-first-served basis, as is common practice in Web applications, etc.).

A member will also have the option to suppress the display of certain details (such as real name, address, postcode).

For security purposes the system will store a scan of a members proof of identity (e.g. birth certificate, passport, driving licence) which will never be displayed to unauthorized members as well as a photograph (which the member will have the option to display). Members will also have the option to display one or more avatars, a voice message, a profile, etc."

Account information
The system will store the following for each account:

• postal address
• geo-coordinates of post code
• account owner(s)
• preferred means of contact
• currencies enabled.

Creating an identity
The software will support some kind of vetting, tutorial, approval or mentoring procedure between members' applications to join and heir acceptance. Typically, new members may create an account online, but need some kind of approval before they can trade in curencies, post messages to the system, see other users' details. This could be expressed as there being a role of unapproved member.

A note on account numbers:
In the original "universal transaction engine" it was proposed that members be given a unique code based on a three letter code for the scheme, and an id, so the first member in CamdenLETS might be CMD0001. It proposed that this be their login, and separate from the username, by which a member is known on the system. This is reminiscent of a bank account number. We need to be clearer about this. Matthew thinks that, like with an email provider, such as hotmail, everyone should have a unique username, which they use to log in and are known by within the system. This is a much more familiar way of working. The three letter code is rather imposing, and the number forgettable and impersonal. Logging in with a username is much more like social networking.

Mary says: Nevertheless, it has to be said that it is common practice in all LETS schemes for members to have an account number, reminiscent of a bank account. Commonly they are only known to other members by their first name (or in some cases a nickname or alias. But often at joining meetings they even introduce themselves by their first name and account number. Given that we all have to remember pin numbers it's not consistent to say that an account number is un-memorable. In fact there are distinct advantages when it comes to compiling outputs because an account number is of a uniform size and more compact than the user-names that people are likely to think up, like for example "stick-in-the-mud" or "crazy-blogger-king", which are really going to wreck a layout.

John W says [Aside: Expanding on what I wrote on 17/03/2007:

For login and membership records I would suggest:

1 membership number
1.1 a unique identifier (an integer > 0)
1.2 the primary key in the membership database
1.3 unchanging
even when user changes own username
1.4 (account 0 = system account?)

2 username
2.1 arbitrary string (not purely numerical)
2.2 chosen by user
if user's choice is already taken,
system recommends alternatives
or
user suggests new choice
2.3 unique within a particular scheme
e.g. oinker@piglets

3 Users should be able to log in unambiguously using
either
membership number
or
username
because
username is not purely numerical

4 Users should be able to change their own usernames arbitrarily (as 2.2), which will cause no problems if (1.2). (Printed copies of listings would be affected if usernames, rather than just numbers, are provided on them, but that problem can be overcome alerting members to a changed user name. This would probably be an unusual event in any case.)

5 User choice is important.Names should not be made up for people (they may not like them).However, it may necessary to reject names that do not fit within defined criteria (including those of taste and decency).

6 Numbers, in contrast, are fairly neutral (except to numerologists and some superstitious types) so these can be assigned arbitrarily. In the exceptional case of someone not wanting to their number (e.g. 13 or 666) this can be skipped over by issuing a request to the system.

7 Within any "local cluster" it would be helpful to allow for the unique identification of a user|currency|system triplet (where "system" means the name of the LCS organization, which may provide multiple currency support, or the name of a branch within that LCS organization).
e.g.

The point here is that following the conventions of *nix style addressing (which is what we have in the form of email addresses, URLs, user IDs, etc.) we define any user uniquely.

Furthermore we can define arbitrary "mapping functions" or "exchange functions" between currencies, e.g.
F[%hours@piglets.org,%joules@clun.energy.org.uk]
Putting aside the arguments for or against ever doing such things, constructing a username|currency|system identifier is very easy using the conventions we already use (in different forms) for other things, with a very short and succinct form for local systems. Therefore I believe an addressing scheme of this sort should be part of the LoCuS specifications.

On the other hand, I believe any prescription on the type of system allowable should _not_ be part of the LoCuS specifications.

The specification of system attributes should be defined elsewhere (as in the "LETSystem Design Manual"), but an interpretation of those
specifications can be prepared as a pre-defined configuration for a LoCuS-compliant system.

NB The use of a CMS (such as Drupal) would provide some of the more basic functions such as (2.2).