Right now, one of my toy project is to build a free software ethical alternative to the trio: meetup.com/facebook events/eventbrite (mainly because there seems to be strictly no alternatives available).
While thinking on how to do that, my initial idea was simply to "simply" do a clone of meetup.com. Not especially exciting. Then I realised that there was a funnier and way more interesting way of doing this. My inspiration came from etherpad and doodle (well, framadate), two website where to start working you just have to click on one big button that say "create to new pad/survey for me" and you're done: no user registration, nothing.
Thus came the logical conclusion on making this alternative userless and seeing how far that idea can be pushed.
In a world where the vast majority of proprietary services try to get as much data as possible in exchange of "free" services and where some governmental agencies seems a bit too curious about what we are doing, I think that it's worth a try for the free software movement to explore how far can we build viable tools while collecting as few personal data as possible (because they can't "stole" data you don't have).
And on the other hand, having a tool where you don't have to register an account really lowers the barrier of entry, thus the adoption. This could be an interesting advantage for free software to offer a attracting alternative (in addition to the ethical part).
So, after thinking about it for some time, here are a series of ways that I will probably implement this idea in this alternative (some of those are already done). The strategy is to ask as few as possible and only ask more when "more" is absolutely needed, a "leveraging" strategy (for now, "more" seems only to be an email address).
For reference, the workflow of the application is:
First idea (from doodle): use unique, hard to guess url:
-> no personal data is stored
when another user answer to the event, only ask for his "name" (a simple text input, no concept of first/last name/gender/other, the user will put what he wants)
Simple additional security idea: allows the event organiser to password protect the event administration page. Same for the event page (for private events).
Simple privacy idea: allow the user to hide his nick from the public list of attendees (the event organiser will still be able to see it).
Another simple privacy (and also convenient) idea: allow the event organiser to not display the attendees list on the public page of the event. This also allows to have a more "eventbrite"/ticketing approach to the event organisation."
Convenient idea for a minimalist privacy trade-off: temporary link the privates page (the ones that have unique hard to guess urls) to the user cookie/session and display them somewhere for the user to get them back.
Another convenient idea: have a simple form to allow the user to send himself an email containing a link to those uniques pages (after the creation of the pages). Something like "send me this link via email". Do not store the mail address.
First leveraging: ask the user to store his email. Do not expose/share this email via anyone, never.
This allows to:
And this adds one very cool feature: add the possibility for the user to have on one page all the places where his email is "linked" to something: event attending and created event. And of course, give the user links to the "unique urls" pages corresponding to those place and to remove his participation/email from those places.
The way to gain access to this page is a simple form where the user puts his email address, this sends him an email with a link to a "unique url" page valid for a certain period of time.
That's all for the big main patterns I've come up with for now (there are small variations/details like "possibility to suppress event"/"give a life time to events"/"suppress my participation"/"put password at those places" etc... that I haven't write down here because I'm lazy and that they don't bring that much).
I'm interested in your opinion and if you have other big main patterns idea on this subject.
And to finish, some downside of this userless approach: