be an oauth provider

[chadwhitacre]

Original: we need an immutable participant id

It's nice internally to use username as the participant_id. It makes it much easier to read other tables, and our db constraints do a good job of handling name changes.

Now that we're starting to implement some partnerships (#89, #443), we need to give them an id that is guaranteed to be immutable (the alternative is to force all of our partners to deal with name changes, which is an untenable architecture).

We should rename participants.id to participants.username, change all indices and keys to match, and then use id for a serial bigint. Username should continue to be unique and the foreign key for our own tables, and id will be unique and what we feed to partners.

[heartpunk]

I think this should be a first step towards potentially building OAuth later, so services can integrate with us, rather than us integrate with them.

[chadwhitacre]

Right. Changing this ticket accordingly.

[chadwhitacre]

FTR, oauth was suggested by @indirect on rubygems/rubygems.org#500.

[indirect]

Rather than add an ID, you can simply track external integrations by the token that they possess, and key the tokens list to the username.

[chadwhitacre]

@indirect Right. I said the thing about immutable IDs before you helped me realize I was starting to reimplement oauth. :-)

[sigmavirus24]

I think being our own OAuth provider would be awesome for #462, but first we might need an alternate way to identify.

[chadwhitacre]

Probably some day. Out of scope for now.