Should access to /list be restricted?

[jonathanperret]

It’s like a pad

In terms of permissions, I’ve always thought of Paysage’s playgrounds as similar to shared pads such as can be created on http://framapad.org and the like. The commonalities are obvious:

• pads are randomly named by default, but you can pick a name if you want;
• anyone knowing the name of a pad has full access.

That last property of pads is only viable because of the next one:

• no one (apart perhaps from site administrators) can see the list of existing pads, or search for a pad.

Note that those properties of pads are also shared by conferencing sites such as http://appear.in and probably many others.

Unfortunately, by publicly exposing the /list view, and documenting it in README, Paysage falls short here: there is no current way to create a space on http://paysage.xyz where a group of people can play together without the worry that a stranger may come and wreak havoc with the collective work in progress. When the tool is used with a classroom for example, one would really like a reasonable degree of certainty that only authorized people can edit the workspace.

It’s also like a game

That said, Paysage can also be thought of as an online game, which gives rise to other, somewhat contradictory with those of pads, properties to emulate:

• spectators are welcome – the potential for artistic performance is obvious here;
• games in progress are discoverable so that people who don’t know each other beforehand can end up playing together.

Again, what makes these properties work for games is that:

• “owners” of a game in progress can decide who can or cannot influence the game.

In this view, Paysage’s /list would be a reasonable, if basic, implementation of the “lobby” of many online games. However, feature parity stops here: there’s absolutely nothing you can do in Paysage to select who is allowed to change code — a “griefer”’s paradise, in short.

Can’t you choose already?

I think the main thing the “pad” view (“the URL is the password”) has going for it is its simplicity, both in implementation and usage: no need for user authentication, permissions management, etc.

But in the longer term, I’d really like to enjoy the benefits of the “game” approach – collaborative coding seems to have a huge potential for connecting people with a shared love of creative coding. This is just going to take some work.

In the meantime, I suggest that we protect the /list page with a password known only to site administrators, leaving to users the decision of whether to share the URL to their playground with people in a room, remote friends or Twitter.

Thoughts?

[juliendorra]

Great summary, food for thoughts! It's quite interesting to reflect on what experience we want Paysage to be for users.

First feedbacks, not in any particular order, just my reactions:

• It could also be considered an (ephemeral) wiki, where everybody can see and edit everything. (and at some point the wiki vanish).

• As playgrounds are not persistent beyond 36 hours in any case, we are at the moment less like a pad.

• In fact I used /list in class because it was easier to share this URL in advance with both classes (45 students in all), when I wasn't sure how many Playgrounds we would open and use, maybe with sub-groups, etc. Then in class I pointed them to the public list, and said: "click on code next to the playground named …". It allowed me to not determine in advance where to point students, but yet send them a link they could just click. Great help (even with empty ghost playgrounds at the time polluting the list)

• It would feel like a premature security lock to restrict a useful tool like /list in anticipation of vandals when we might not have vandals for many months to come. Said more bluntly: we have so few users, why be afraid of them? We'll have vandals when we'll have vandals, and then the right solution might appear a lot more obvious. (it might not even be a technical solution, depending context.)

• We might also think of Paysage as a huge park with as much sandboxes as you might want. You can wander from sandboxes to sandboxes, call one your one, invite friends there. But, yes, a kid from another sandbox might come and want to play in your sandbox. Maybe you'll need to share your tools, but there's also a chance that the new kid will share theirs, and you'll be happy they dropped by!

• I dislike the idea of having two level of users, and don't see the benefit. It is much more fertile to think of a system where all users can assume all roles, not necessarily all the time, but when they are up to it. For example, if we build a /debug page, dedicated to only logging the errors from all objects from a Playground, it would be sad to restrict it to "super users".

• We added an unrestricted delete feature. It shows that we probably tend on the "let users build their own rules on what is a polite behavior" side. Maybe this could also guide us in term of Playgrounds publicity and behavior when user enter an unknown playground?

Wow, sorry, it's a lot of unstructured feedback! Hopefully it helps.

[juliendorra]

one more:

• we can take the stance that this impossibility to have an enclosed "Playground just for us" is the only social rule we enforce. That we want for classes to have intruders that might create with students with the teachers not having a say, that we want as much chance encounters and creative frictions as possible. That the risk of vandals is worth it if it allows everybody to roam free. That on Paysage, code is for everyone to see and change.

Of course it's a political stance, not a technical one, and it's not easy, as we are so used to every tools working in closed mode by default (except Wikipedia, maybe). There's a cost (vandalism, but you need either enemies or to be mainstream for that), but there's a huge gain in learning, trying new things and not restricting any user in their contributions.

There's not much places on the web to explore what happens when everybody can change everything. It would be nice if Paysage could be one.

End of lyrical techno-communist comment

[etienneCharignon]

We could also give a mean to users to hide one playground from the list. A sort of « go private for this one ». Or like in https://scratch.mit.edu/ an opt-in mecanisme « share my project » would make it appears in the list.

[juliendorra]

Implementation proposal: We automatically hide in the list the playgrounds which names start with COWARD or SELFISH. So you have to openly declare your fear to be attacked or your desire to cut your code off from others ;-)

Kidding, kidding, but not that much.

My feeling is that this issue is not about "how to do it", but rather about:

"Why do it? Is that coherent with what we want Paysage to about? Who would benefit and in what situation? What would be gained or made possible? What would be lost or made impossible? Would it be reversible? Is the current situation reversible?" So it's a question about the values of Paysage, and a challenge to define a common view of the motivations and missions behind it.

I'd love more feedback from you all on the values aspect (rather than implementation solutions), because defining now a common core of values about Paysage, about collective creating coding with Paysage will help a lot in the future. If we can't, we'll have either endless discussions, or "I added this feature, so live with it now" (do-ocraty can have bad side-effects, I have seen them in the Drupal France and Museomix communities).

As an example, it helped a lot to have defined and clarified the basic values and missions for Museomix just after the second event (early 2013) and before fully opening the format, and it's still an useful core to refer to years later for the new organizers and contributors.

[etienneCharignon]

I thought that citing scratch would be enough discussion about values ;-)

Kidding, kidding, but not that much.

Sometime we can open a discussion by giving some other path (through solution proposal in that case).

Concerning the feedback on values, I'm fully aligned with you previous comment, even to the "extreme" of techno-communist comment. I'm really attached to the kind of freedom that we have today.

However, I dislike the "list page" as it is today and would be pleased if we could find a better way with it.

Side thought: I'm also thinking about the ephemeral aspect of paysage today and this discussion is also going on that area (but really going away from the initial question). Wouldn't it be breaking something to implement persistency ?

[juliendorra]

I thought that citing scratch would be enough discussion about values ;-)

We all love Scratch, and the Scratch sharing platform is a great enhancement. But there's some values embedded in Scratch that we might not want to carry along in Paysage: Teaching as the main purpose, the notion that projects are first and foremost an individual's work and pass from individual to individual without never really being collective, pseudonymity, etc.

Sometime we can open a discussion by giving some other path (through solution proposal in that case).

You're right! Thanks, it worked :-)

Side though : I'm also thinking about the ephemeral aspect of paysage today and this discussion is also going on that area (but really going away from the initial question). Wouldn't it be breaking something to implement persistency ?

I grew fond of this ephemeral aspect. We stumbled upon it merely because it was the easiest thing to do, but it has beneficial consequences. In a way it's very zen, or at least opposed to the western values of keeping everything, of curation and heritage. It's akin to building an incredible mandala together, and sweeping all the sand at the end. In fact it is a closely related issue, as it is also about values and how different from other tools Paysage should be. I think we all share the view that Paysage should be as different as possible from other tools, in term of values and general experience. It's already unique in several aspects.