Title: Primary vs. Secondary Registration

When you design a Lamson application the question of "registration"
comes up almost immediately.  The question is one of how you find out
who a person is so that you can interact with them.  In the web world
this involves a form of some kind asking for a login and password at a
minimum.  Some sites even go so far as to require a sign-up process
*before* they let you see anything about the site, or even their marketing
material.

On the web this kind of registration is what I like to call "Primary
Registration".  It comes from the concept of primary vs. secondary data,
or primary vs. secondary analysis.  In the world of measurement a
primary source is one that you gathered the information from directly,
usually by giving them a questionaire.  A secondary source is one that
you gathered in some indirect way, either by evaluating past research
in a new way, data mining, or simply unobtrusive data collection.

With a web site you *must* have a primary registration system.  There is
no implied identity in a browser that is consistent for a user, so you
need to ask them for some information and associate their stateless
browser to a cookie or similar tracking mechanism.  You have to do this
for each session you start with them, and to register them if your
service requires some kind of password protection.

In the world of the web primary registration is just how things are
done.

h2. Secondary Registration

Lamson give you the ability to do *Secondary Registration* where the act
of interacting with your service *is* the registration.  A typical
primary registrationg process will ask for a user's email address to
identify the user, but in Lamson the user actively gives your service
their email address to start playing.  Their first message to your
service actually has all the information you need to sign them up and
give them their first taste of your service.

In fact, a user's identity is so baked into the email protocols that your
Lamson server has almost the inverse problem:  it's too easy to fake an
identity, so you need to confirm their subscription and important
actions.  This confirmation is traditionally nothing more than a reply
asking them to reply with some random number in the address.  If you get
a reply to this auto-generated email address then you assume they are
real.

bq. This "random number confirmation handshake" is important because
SMTP allows anyone with an internet connection to lie about who they are
and craft a fake email claiming to be someone else.  The confirmation
assures you that the supposed sender has at least received an email in
their inbox and that it had the random number you generated in the reply
address.  A determined hacker could also get past that, but if you have
that situation you are dealing with more problems than just
confirmations.

Once you do though you are fairly assured that they are
identified *and* using your service.  It ends up being the most low
effort entry to your service you could possibly devise without making
the service unsafe.


h2. Comparing Two Designs

When you sit down to build a Lamson application you may still think
about registration in the primary way, but a secondary registration is
typically more natural for an email service.  To illustrate the point,
let's say you are creating an online game using Lamson, and you want
people to register for the game.

With a primary registration you would approach the problem by making
your game open only to registered users.  If they send an email to
your game you send a single reply pointing them at the web page they can
use to sign up.  You also then take every email and pass it through a
filter that checks that the user is registered in your subscription
database.  This is mostly how you would do it in a web application.

bq. Maybe there is a legitimate reason to force a user to a web page to
give a password and other information before using the service.  If
that's the case, then go for it, but consider trying to make the *entry*
to your service a secondary registration that then asks them to do a
full registration to get more features.

With a secondary registration system, you are using Lamson's ability to
track the state of every user to know whether they are registered or
not.  When your game receives their first email, it would transition to
an @UNKNOWN@ state and reply with a confirmation email.  Once they reply
to the confirm email you transition from @UNKNOWN@ to the rest of the
game since they are now registered.  Every interaction after that will
simply know they are registered because they are in the right state.

This has a big impact on your game's design because now you do *not*
need to check the database on every received email to confirm their
identity.  Their email address and their state in your state's storage
tells you that implicitly.

You can also extend this to other requirements for your system.  You can
use their known state to transition them from free to paid quality
services, to suspended states, to pause them after a bounce, and back to
normal activity.


h2. Invite Only Systems

An invite only system can also use the secondary registration technique
by having the inviter's invitation request create a record for the
invitee that's in the right start state.  When the inviter tells you to
invite their friend, you create a state for the friend that says
@INVITED@ and use the invite as a sort of implied confirmation email.
When the invitee replies to this invite email, you transition them to
the rest of the system as they've now registered.

Another way to think of an invite only system in Lamson is as a
3rd-party confirmation.  Rather than the target user (the invitee)
prompting a confirmation, it is their friend sending the invite (the
inviter) who triggers the confirmation process on behalf of their buddy.

An additional bonus with Lamson is that the state of the invitee is
known, so if the inviter tries to send them again, or if someone else
does, then you know they already were sent an invite.  You can just
ignore the request and avoid spamming people.  You can also run reports
to find out your conversion rates by simply looking for everyone in the
various states and counting.


h2. Security And Design Issues

Doing these kind of secondary registrations and implied identity does
come with an extra security penalty.  Unless your system is
incorporating S-MIME or GPG you won't have a solid way to identify the
sender.  You don't have this on most other internet services either so
it's not much of a loss.  At least with email you have a higher
assurance that this is a real person.

When you design your service it's a good idea to:

# Either make everything the user does non-destructive,
# Send confirmations for anything desctructive,
# Or bounce them to a web site for more complex interactions and security.

You should also make any confirmations you send easily replied to, but
have a good random number in them that you remember for later.

bq. In the examples that Lamson has as of the 0.9 release this advice
isn't followed for teaching purposes, which is why it's important to
write it down here.


