Owkaye, Thanks for the comment and suggestion.
The problem with implementing this locally at associated web sites rather than centrally at twitter is that: - each site would have to implement it separately; and - users would have to sign up and create a private ID at each site they use. That results in much confusion and duplication of effort both for web site developers and users. It would be be much less confusing and require much less total effort if it were done centrally. That said and given twitter's priorities and available resources, I don't expect them to implement this scheme or anything like it. And, at this time, we don't even know if this is a real issue or just a red-herring. I raised it because I saw it as a theoretical problem with the proposal, not because anyone that I know has experienced this problem. Does anybody see this as a real or potential problem, or should we just let the issue fade away? Comments expected and welcome. Jim On Jul 22, 3:28 pm, owkaye <owk...@gmail.com> wrote: > > One solution to this problem is to add to each twitter > > account another "private" ID. > > Jim, > > Wouldn't it make more sense to implement this "private id" > thing on your own server? > > My thought here is that your service should maintain its own > database of users, and issue a unique "private id" for each > of these users. > > Then when the visitor tries to login, your code can check to > see if the private id the visitor has entered is in your own > database. If so the person is allowed to login, and if not > they get an error. > > Would this work to solve the problem of am I missing > something here? > > Owkaye
