Hello all. I'm sorry I did not pay attention to Google Wave earlier. I was having since many years a project http://trust-forum.net/ based on important common ideas with Google Wave. But I'm not a programmer and I was not lucky enough to find good programmers to implement it. Only recently I found some to start working on it (from scratch discarding a previous prototype). Just now looking at Google Wave in more details I see that it is so good and with enough coherence with my ideas that I want to integrate it with my project. But I'm afraid the first changes to make from the current version of google wave (to shape it into what I considered as the foundation of my project) may be hard to make because they involve changes at the root of the system, and may require to rebuild a number of things. Please tell me your opinion on this question. There are two fundamental missing features I wish to add, both about user identity issues (even if only the second one affects the protocol itself, the other below remarks are still important to the foundation of the whole Wave system).
1) Multiple pseudos per account. Some users may need to join groups anonymously, under a pseudonym that other people (except the system admin) would not be able to trace to another public identity of the user. Still it can be interesting for the user to be able to operate all his activities from the same account, in order to keep track of all events immediately without bothering to log in and out all the time. This has another important consequence: to make it possible for a user to stay anonymous, it should remain optional to join a picture to an identity. But then, what can appear instead of a user's picture, where I see that all users in a wave appear in the form of pictures ? If you say: what about cheating by using several identities to mascarade as a group when one is in fact alone ? Well... those who want to do this sort of cheating could do it in any case by creating several accounts. Then, in the future developments I envision, multiple pseudos per account will have more advantages: to simplify the internal calculations of trust connections so that trust to a user defined by a pseudo simply benefits all the pseudos of the same user. Also in case of troubles (complaints against the user) or other circumstances, it makes sense for the underlying system and/or system admin, to keep track of the list of pseudos that belong to the same user. 2) Automatic remote authentication under a chosen pseudo. Here is the problem: To be able to operate all private conversations and contributions to public forums from the same account is nice; being able to integrate in waves some robots representing interactions with any other sites, goes one step further; but I'm afraid in some cases it may still not be as convenient, powerful, secure and flexible as could be a direct connection by the browser to a different web server. Indeed, we are facing the following alternative: - Either, Wave Servers are going to evolve into the role of Universal Proxy Servers to their users, removing the use for an address bar in browsers (all requests of a fixed user to the whole web being technically addressed to the same server where the user is registered) - Or, users will remain bothered with the necessity to create a new login and a new pseudo every time they want to use another service where they need an identity and that is not a standard wave function but can better be operated by directly connecting the browser to a different server where that service is implemented. This way it is not only bothering to register and log in again at every use, but it might also make it unnatural to produce the certification that a user acting in 2 different sites is the same person (even if it is possible to do something in this direction). - Or, a remote authentication procedure such as I defined in my project will be added to Google Wave, which will lead to the distinction between different kinds of sessions of a user to a server: Those of local users; Those authenticated as a user of another server; Anonymous sessions that are read-only access to public data but still letting the possibility for the user to operate from there to his home account, thanks to the authentication of the browser to the home account. The problem is: ifever we also wish the Google Wave system to be able to serve such remote users, how hard will it be to adapt its core to such a distinction between different types of users ? (Another point will be to allow for a diversity of access right levels to waves or wavelets, namely including the read-only level and moderator level, and of systems of how to compute such rights, that in the future I will want to extend to other criteria than the presence in an explicit list.) Thank you for your attention. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
