Historic:Migration of users from Slashdot: Difference between revisions
(→Password Requirements: ObXKCD) |
|||
Line 35: | Line 35: | ||
* Necessary evil? | * Necessary evil? | ||
* Min password length, sure. | * Min password length, sure. [http://explainxkcd.com/936/ Correct horse battery staple], of course. | ||
* Password expiry, no. | |||
* Also, there should be no limitation on what goes into a password field. It's all going to be salted and hashed anyways. | * Also, there should be no limitation on what goes into a password field. It's all going to be salted and hashed anyways. | ||
Revision as of 23:08, 11 February 2014
The problem
Slashdot users are a community, where users are known by nicks. Starting with a new set of nicks would disrupt the years--long network of acquaintances, etc.
Preserving nicks
A simple system could be build, which would allow for safe and authorised migration of nicks of willing users.
If anyone would want to register on Altslashdot with a nick that already exists on Slashdot, the user would be presented with a generated key. The user would then need to post any comment on Slashdot, that would contain that key. The migrating user would then present a link to that comment in the registration form..
Then, we would know, that a user with a nick we know from Slashdot is really that user, and not a copycat.
All nicks used on Slashdot would be reserved to be taken by their respective user to the new site,
- either for a certain period of time (one year, for example);
- or without any limit, for late-comers, to avoid trolling, and to encourage nick-innovation among new users.
To avoid polluting the public forums, the user might attach the key to a regular comment, or post it in Journal instead
Note: this must be new, as I registered here using my slashdot name with no code. My slash UID is 5 characters, alt UID 3.
Preserving UIDs
As above with Preserving Nicks, UIDs are a valued commodity. When AltSlashDot goes online, it should determine what the last registered UID on Slashdot is at that moment. That is the Cutoff UID.
- Anyone who registers will get an initial AltSlashDot UID, which should start at 1.
- They also get a Slashdot UID, which is initially null and won't be displayed
- Once someone confirms their account, their Slashdot UID should also carry over
- When posting, both UIDs should be displayed with ??? UI-- like halcyon1234(834388 /.) [2 alt/.]-- obviously in a UI that doesn't suck. =)
Suggestion: 2 UIDs seems overly complex. Why not use the original Slashdot UID for those who verify them, and otherwise hand out new UIDs starting with (Cutoff UID +1)?
OP of UID-- I think Cutoff UID +1 would work perfectly, I agree 2 UIDs would be complex.
UID Requirements
It seems a lot of people tend to lean towards 3 characters instead of 5 as from my understanding new slashdot requires 5 characters? Don't know if this is true but I think it would make people happy to have 3 character minimum.
Password Requirements
Uppercase / alpha-numerical combinations as a requirement should die in a fire. What do you guys think?
- Necessary evil?
- Min password length, sure. Correct horse battery staple, of course.
- Password expiry, no.
- Also, there should be no limitation on what goes into a password field. It's all going to be salted and hashed anyways.
Copyright of content
Let's remember that the content on /. is likely protected by copyright, which also means its database of users and their posts. However, it doesn't seem like any search engine is getting into hot water for indexing users so I think we will be okay if a spider is built for reserving names.
- All posts are owned by the person who posted it. (Check the footer of Slashdot after the Slashcott). Wholesale spidering MAY violate some mysterious TOS or be interpreted as a DOS. However, is there anything wrong with spidering the Wayback Machine?
- Using the Wayback Machine may be a better option altogether. There's a chance that Dice gets all lawyery about all of this and scraping anything from their site gives them a case. At the very least, they could block access attempts and jam up the migration attempt.