"rooms" in tiddlyweb

[Michael Mahemoff]

I wanted to get a discussion going about the concept of "rooms" (aka
"spaces"/"groups") in TiddlyWeb apps. We've talked about this in
Osmosoft a bit and see it as a fundmental concept of many apps going
forth. (Somewhat related, but we've moved on a bit since then:
http://groups.google.com/group/tiddlyweb/browse_thread/thread/243f2966f2e30724/ed09c0e2b29984e4)

"Rooms" are user/business-logic concepts, and we need to find a way to
map them into TiddlyWiki/Web concepts, so that it's consistent and we
can then build plugins making certain assumptions.

In TiddlyDocs, for example, each "room" is a group of people who can
share documents together. If you're only in room A, you have no
visibility on content in room B. Some of the early design is described
at http://softwareas.com/tiddlydocs-user-authentication-generic-design-and-custom-features,
but maybe Simon or Ben can provide an update on that.

In general, there are two ways to architect a collaborative tiddlyweb app:
* single-room: everyone can see everything (generally speaking). If
you want a new room, you need to start a new instance of tiddlyweb
with a new store.
* multi-room: as in TiddlyDocs, many rooms, each with their own set of users.

While rooms in an app like TiddlyDocs are basically the same kind of
thing, they don't have to be. A more general TiddlyWeb-backed
TiddlyWiki server could support different rooms for different things.
e.g. room A is some people using TiddlyGuv; rooms B and C are some
people using TiddlyDocs; room D is New Ideas with SinglePageMode
bolted on for good measure; room E is a homebrew of several
graphics-related plugins with some custom code. (All this assumes the
functionality only varies according to client/TiddlyWiki plugins; the
server plugins and config remain the same for all rooms because it is
just the one server.)

So what I've stated above is my idea of the basic requirements for
such a thing. I'd like to know if (a) people agree these requirements
are useful; (b) how they might be actualised as an imlpementation on
top of TiddlyWebWiki. For example, is a room just a recipe? How does
the whole model fit together?

[Chris Dent]

On Dec 16, 2009, at 12:37 AM, Michael Mahemoff wrote:

> I wanted to get a discussion going about the concept of "rooms" (aka
> "spaces"/"groups") in TiddlyWeb apps. We've talked about this in
> Osmosoft a bit and see it as a fundmental concept of many apps going
> forth.

Glad this is getting started, it will be good to flesh this stuff out so we can all be on similar pages when we talk about authorization issues in TiddlyWeb.

> "Rooms" are user/business-logic concepts, and we need to find a way to
> map them into TiddlyWiki/Web concepts, so that it's consistent and we
> can then build plugins making certain assumptions.

I've found that I really struggle when reading descriptions of rooms and the like (such as those in the links you provided) because I struggle to map the concepts onto my own understandings of how recipes, bags, policies and roles work. That is, it seems like the understanding of recipes, bags, policies and roles (henceforth RBPR) used in describing rooms/space is not or the same as mine.

Or perhaps there is a different in the extent to which I think it is okay to manipulate policies and roles within code.

> In TiddlyDocs, for example, each "room" is a group of people who can
> share documents together. If you're only in room A, you have no
> visibility on content in room B. Some of the early design is described
> at http://softwareas.com/tiddlydocs-user-authentication-generic-design-and-custom-features,
> but maybe Simon or Ben can provide an update on that.

How is this different from two bags with two different policies? Is "room" a label for describing a way of managing bags, or is it an entity that is reified in the system in some way?

An important piece of the recipe/bag puzzle is that if _any_ bag in a recipe does not pass the read constraint, the current user cannot read the current bag.

> In general, there are two ways to architect a collaborative tiddlyweb app:
> * single-room: everyone can see everything (generally speaking). If
> you want a new room, you need to start a new instance of tiddlyweb
> with a new store.
> * multi-room: as in TiddlyDocs, many rooms, each with their own set of users.

Again, I see this as making a statement about a thing called rooms, for which there has been no statement of requirements and by using it the full flexibility of RBPR is being limited.

Every time a new bag or recipe is created, it's policy can be set to whatever the system designer wants it to be.
The policy can be changed any time the system designer wants it to be.
The policy can be dynamically altered in place, temporarily, per request, based on environmental conditions.

Every time a new user is created, they can be given whatever roles are required as defined by the system designer.
These roles can be change any time the system designer wants.
Every time a user is instantiated, per request, their roles can be dynamically set or altered, per request, based on environmental conditions.

Recipes and bags are designed to be cheap to create, cheap to use, and cheap to destroy. It's okay for a system to have loads and loads of them. Similarly it is okay for a system to have loads and loads of roles. A thing lacking in the TiddlyWeb-sphere are the tools to easily manage and inspect these loads and loads of stuff, so I think people are tending towards systems which use as few RBPR as they can get away with. I think this is the wrong approach.

It may be that the mental model for the association between bags, roles and users is not clear. Probably because there are several. In my model of a large scale multi-user TiddlyWeb installation, when a bag is created that is supposed to have limited access the creator of the bag makes some decisions:

1. Do I want to limit this bag to some named users?
2. Do I want to limit this bag to some globally existing role or roles?
3. Do I want to limit this bag to some roles that are specific to this bag, or in some namespace that are special to me?

Each imposes a different thought model. 1 describes a fairly small scale, tightly controlled, high maintenance situation. 2 describes a situation where the bag creator is willing to offload some trust onto whatever manages the globally existing role. In 3 the bag creator has tighter control than 2.

In both the 2 and 3 case, a user needs, through some mechanism, to gain the role or roles involved in order to subscribe to the bag involved.

Implicit in that is a separation between the creation of a contained "space" and the actions done to let people in. In 2 or 3 above the "let people in" is done by modifying the people, not by modifying the space. The space has already been defined.

> While rooms in an app like TiddlyDocs are basically the same kind of
> thing, they don't have to be. A more general TiddlyWeb-backed
> TiddlyWiki server could support different rooms for different things.
> e.g. room A is some people using TiddlyGuv; rooms B and C are some
> people using TiddlyDocs; room D is New Ideas with SinglePageMode
> bolted on for good measure; room E is a homebrew of several
> graphics-related plugins with some custom code. (All this assumes the
> functionality only varies according to client/TiddlyWiki plugins; the
> server plugins and config remain the same for all rooms because it is
> just the one server.)

These all sound like bags or recipes to me? Why are they rooms?

> So what I've stated above is my idea of the basic requirements for
> such a thing. I'd like to know if (a) people agree these requirements
> are useful; (b) how they might be actualised as an imlpementation on
> top of TiddlyWebWiki. For example, is a room just a recipe? How does
> the whole model fit together?

a) I've not actually read requirements in what you've written. What I've read is description of "named thing" which is proposed as a solution to a problem which itself is not as well described as I think it needs to be. It feels like you've basically said, "there need to be rooms and they maybe should be like this". I think we need to step back and do the step before concluding that there need to be rooms.

b) It does seem like for the most part a room is a recipe, but I'm still a bit confused on what business-logic problem/need a "room" or "space" solves or enables.

[Ben Gillies]

> In TiddlyDocs, for example, each "room" is a group of people who can
> share documents together. If you're only in room A, you have no
> visibility on content in room B. Some of the early design is described
> at http://softwareas.com/tiddlydocs-user-authentication-generic-design-and-custom-features,
> but maybe Simon or Ben can provide an update on that.

Within Tiddlydocs, I'd phrase it as each room being a collection of bags, along with a recipe (just the one in TiddlyDocs, though this does not necessarily have to be the case) that together provide a core set of functionality that is separated in terms of access between different groups. Fundamentally, a room (or space) is no different than RBPR and could in theory be managed in the same way (along with whatever policies you want).

The differentiating factor I believe, is that a room defines a basic (enclosed) set of functionality. By this I mean the default minimum set of bags/recipes required in order to get the required degree of separation for that user/group. I think of this as like a mini instance, that allows one user/group to customise/add/edit their own stuff (this may be core interface-y type stuff or it may simply be info/comments/etc), while still leaving other users/groups unaffected.

This is not to say that bags in one "room" need to be kept completely separate from those in another room (reporting may be a good example of when one would need access to bags from multiple rooms).
 

How is this different from two bags with two different policies? Is "room" a label for describing a way of managing bags, or is it an entity that is reified in the system in some way?

It's not really any different from two bags with two different policies. At the end of the day, its all just bags, recipes and policies.

 

Again, I see this as making a statement about a thing called rooms, for which there has been no statement of requirements and by using it the full flexibility of RBPR is being limited.

I see a room as a useful way of managing the process of keeping things separate. Its much easier to manage that process if you've got a common name that you can prepend onto all the bags and recipes that relate to a certain group, and that you can then use when setting the policies of said groups (ie - restricting access in some way by creating/adding a role based on the room name).
 

Every time a new bag or recipe is created, it's policy can be set to whatever the system designer wants it to be.
The policy can be changed any time the system designer wants it to be.
The policy can be dynamically altered in place, temporarily, per request, based on environmental conditions.

Yes, but if a new group comes onto the system, they will need a common set of bags/recipes before they can get going. It makes sense to create all of these at the same time, as they are all closely related (all belonging to the same group). Of course, there would be nothing stopping you adding another bag to that "room" at a later date, or just adding extra bags/recipes whenever/wherever you like anyway.
 

Every time a new user is created, they can be given whatever roles are required as defined by the system designer.
These roles can be change any time the system designer wants.
Every time a user is instantiated, per request, their roles can be dynamically set or altered, per request, based on environmental conditions.

If a new user is added, and you want to give them access to that group/room, then you'd simply give them a role corresponding to the room name, as every bag/recipe within that room would have common room name based policy settings. 

 

Recipes and bags are designed to be cheap to create, cheap to use, and cheap to destroy. It's okay for a system to have loads and loads of them. Similarly it is okay for a system to have loads and loads of roles. A thing lacking in the TiddlyWeb-sphere are the tools to easily manage and inspect these loads and loads of stuff, so I think people are tending towards systems which use as few RBPR as they can get away with. I think this is the wrong approach.

If you give each group 4 bags and 2 recipes (1 config bag, 1 bag to store private stuff, 1 for comments, and 1 for public stuff. Plus 1 standard recipe, and one public recipe (maybe for reporting)), and the system has 30 different groups on it, then that's 120 bags and 60 recipe. Maybe at a later date, one of the groups wants to split their private content up into a number of different bags (say 3 different private bags for different types of information). You then have 122 different bags. I don't think this conflicts with the idea of multiple bags at all. If anything, it makes managing access to that many bags that much easier (as you have a common naming scheme (based on room name) through all of the bags, recipes and roles).

Implicit in that is a separation between the creation of a contained "space" and the actions done to let people in. In 2 or 3 above the "let people in" is done by modifying the people, not by modifying the space. The space has already been defined.

Correct. If somebody leaves a group (in real life) that has their own space (on TiddlyWeb), you'd just remove the corresponding role from their user account, and they'd then lose all special access to all of the content associated with that group. In the reverse (somebody joining the group), you'd just give them that role.

In summary then, a room (or space, call it what you will), is nothing more than bags and recipes (with policies attached to them, presumably). It's not really anything tangible in the way that, for instance, a bag is. Its just a useful way of automating creation of a pre defined set of bags and recipes, and managing access to them via a common naming scheme (the "room name" if you will).

Hope this helps



Ben

[Michael Mahemoff]

>>
>> Recipes and bags are designed to be cheap to create, cheap to use, and
>> cheap to destroy. It's okay for a system to have loads and loads of them.
>> Similarly it is okay for a system to have loads and loads of roles. A thing
>> lacking in the TiddlyWeb-sphere are the tools to easily manage and inspect
>> these loads and loads of stuff, so I think people are tending towards
>> systems which use as few RBPR as they can get away with. I think this is the
>> wrong approach.
>
> If you give each group 4 bags and 2 recipes (1 config bag, 1 bag to store
> private stuff, 1 for comments, and 1 for public stuff. Plus 1 standard
> recipe, and one public recipe (maybe for reporting)), and the system has 30
> different groups on it, then that's 120 bags and 60 recipe. Maybe at a later
> date, one of the groups wants to split their private content up into a
> number of different bags (say 3 different private bags for different types
> of information). You then have 122 different bags. I don't think this
> conflicts with the idea of multiple bags at all. If anything, it makes
> managing access to that many bags that much easier (as you have a common
> naming scheme (based on room name) through all of the bags, recipes and
> roles).

Right - rooms are more of a UI/userland concept than anything in the
system necessarily. I see a room being created with certain bags and
recipes. For example, when a user Jimmy creates a room called
"musicians", the system:

* generates roles called "musicians" and "musicians-admin". (Ideally
just "musician" using Rails-style inflection, but I won't go there!).
* add "musicians" and "musicians-admin" roles to Jimmy's user record
* generates "musicians-config", "musicians-comments", etc etc bags
with the policies you'd expect on each. e.g. "musicians-config" can be
read by the new "musicians" role and changed/deleted/managed by the
"musicians-admin" role
* generates a "musicians" recipe with all of the above bags

With the defaults above, the room creator is sufficiently empowered to
knock themselves out, once the room exists, with a tiddlywiki-embedded
tool like TiddlyRecon, creating and destroying new bags and recipes to
their heart's content, and updating policies as they wish.

I'm aiming for this default model to be as simple as possible as I
think that's the only way we can and should get up and running in the
immediate future. So I'm not concerned with multiple recipes per room,
not concerned with public content (because it raises all sorts of
questions about user confusion - it's an extremely useful thing to
have, but right now I think it's going to be a distraction from the
big picture), not concerned with sharing bags between different rooms.

>> Implicit in that is a separation between the creation of a contained "space" and the actions done to let people in. In 2 or 3 above the "let people in" is done by modifying the people, not by modifying the space. The space has already been defined.
> Correct. If somebody leaves a group (in real life) that has their own space (on TiddlyWeb), you'd just remove the corresponding role from their user account, and they'd then lose all special access to all of the content associated with that group. In the reverse (somebody joining the group), you'd just give them that role.

In the "musicians" example, the question translates to: how does jimmy
attach "musicians" and "musicians-admin" role to would-be room
participants, and unattach the role later on, given that they don't
have permission to change the user. I don't have any great answer
there, other than to build special server-side plugins modelled on
other systems. e.g. jimmy invites users by specifying their emails
and/or tiddlyweb user IDs, they get an email, and the system lets them
join. Also, users can request access to a room, which Jimmy will then
be able to yay or nay. Likewise, jimmy can select a user from a list
and kick (in irc parlance) them from the room.

We would have to assume certain naming conventions here: because jimmy
has role "musicians-admin", the plugin lets him instigate the process
of attaching/unattaching "musicians" and "musicians-admin" role to any
other user.

[Michael Mahemoff]

I wrote about the multi-user concept at a high-level on my blog, and
I'd encourage any interested parties to have a read as there are
floating bears and a thousand flowers involved:

http://softwareas.com/multi-user-tiddlywiki

I've switched off comments on that post to encourage them to go here instead.

[jnthnlstr]

Mike,

> I wrote about the multi-user concept at a high-level on my blog, and
> I'd encourage any interested parties to have a read as there are
> floating bears and a thousand flowers involved:
>
> http://softwareas.com/multi-user-tiddlywiki

Coolest thing about your vision - I thought - was the idea of a
standardised piece of software that you could install on your
enterprisey server and get a TiddlyWeb MU going whereby ANY app you
wanted to create was creatable. In doing this, you make a simple path
for people to get started with TiddlyWeb, even if it means they end up
downloading and installing more than they need. For people with an
advanced understanding, they can use one of the paths we're talking
about in the "packaging" discussions.

I liked the story too.

J.

[Michael Mahemoff]

Thanks for the feedback Jon. I should make it clear that the general
concept is not just my vision, but something we've bandied about in
Osmosoft and also an idea you've contributed to yourself :)

Also, although I've focused on the enterprise concept, it could easily
work as a public internet service too. Perhaps with some tweaks, like
different subdomains per rooms for security (and branding and SEO)
purposes and tighter constraints to enforce partitioning.