Codebase
How committed are people to the LJ codebase?
I have been working on a Django-based replacement for LJ, something that is still heavily community-based the way LJ is, but with some improvements for some of the specific ways people have creatively used LJ. I went with Django for scalability reasons, and there are some design things specifically aimed at hosting an LJ-sized community. The effort's been sort of stalled for a while for a variety of reasons, but I still think it makes sense and I could certainly make some time for it.
Here's a collection of notes:
Basic Model:
- Account: represents a billing entity which pays (or doesn't) for service. Has at least one Identity, may have more than one.
- Identity: a posting identity, has Avatars (nee userpics), can make posts and comments. May have a single Journal.
- Do multiple journals in one identity make sense when you can have multiple identities? Examples each way might be good.
- Avatar: a small picture representing the user. Also called userpics, user icons, etc.
- Group: a collection of Identities. Has no other inherent meaning by itself.
- Journal: a collection of Entries. Has one Account which owns it. Has at least one Identity allowed to post to it.
- Entry: a single post in a Journal made by a particular Identity. Has threaded Comments associated with it.
- Comment: a single reply to either an Entry or another Comment made by a particular Identity.
- Community: a Group (members of the Community) and a shared Journal. The Account that owns the Community also owns the Journal and is the final administrator for the Community. Other Identities may have other rights (moderation, membership control, announcements, etc).
Yes, a Community is a small but significant extension of a Journal, mainly to provide membership management. By default everyone on the Members Group will be in the Posters Group of the shared Journal, but that's not required.
- Other possible model elements:
- Polls
- Voting/Rating
- Tags. I'm thinking this might be a decoration thing rather than a first class model element. I'm not sure yet.
- Memories. See Tags.
The default setup is something like an Account with a single Identity and a single Journal, with appropriate permissions. Obviously, though, this model allows many variants.
Other useful concepts:
Permissions:
Entries can have permissions on them saying who is allowed to read them. Public, Posting Account Only, Posting Identity Only, Reader Logged In and Group based permissions are all allowed. Permissions on an entry apply implicitly to the Comments in that entry.
Journals and Identities can have default permissions that will be used to post Entries in that Journal or by that Identity, respectively.
Question: Does it make sense to even try to have comment-level permissions? I suspect they'd be rarely used and more confusing than they're worth.
A Journal has a "Posters" Group which defines who's allowed to post to it.
A Community has a variety of permissions associated with it that will need their own Groups. Member management is the biggie here.
Question: Does Entry moderation live at the Journal level or the Community level?
Reading lists:
An Identity (I think this is the right level for this) can have one or more Groups associated with it as reading lists. By default there are two special groups, "Everyone" and "Default View". Adding anyone to any Identity's Group will also automatically add them to that Identity's "Everyone" Group.
Things to consider:
The "Everyone" group gives an easy way to do what LJ friends do now: add someone to your Default View and give them permission to read posts with "Everyone" permission. Of course, "Everyone" is tighter than "Reader Logged In" or "Public". Given that, "Everyone" may be the wrong name for it...
Should Accounts have this as well, so a given Identity's "Everyone" group would be the merge of that Identity's "Everyone" group and its Account's "Everyone" group, and so forth for other groups? I can see usefulness in this, but it might just confuse people too.
Groups should be able to include Identities from other sites running the same codebase. This would trivially let you have a multi-site reading list. (And, incidentally, multi-site Communities, also a bonus.) It seems pretty straightforward to me if we do Identities right.
Notification:
Obviously, we need a list of possible events about which a user can request to be notified, and a page for managing such stuff. And we actually need to do the notifications when they happen.
Miscellany:
- Recent activity? "RPG Console"...
Hardware Architecture:
The trick to this is scalability. We need to be able to host the site on a basic machine with everything colocated for getting started (and for smaller member sites) and we need to be able to run in a full multi-tier configuration, with database servers, memcached, separation of static and dynamic content, and so forth.
Django has a lot of potential here. RESTful architecture seems like a good principle for coexisting well with caching and the static/dynamic split.
Being fundamentally multi-site distributed will help with the scalability. I really like the idea that smaller subgroups can set up wherever they want and join the community and support most of their own load. (That said, a centralized site is probably useful to coordinate things and be the one that has all the caching set up well.)
Federated Community:
The simplest way to get this is for IDs to be global (e.g. by including the site name in the ID somehow). RESTful architecture suggests that everything is a URI anyway, so that might work well. We can still use numeric IDs locally; an unadorned numeric ID is obviously a local one.
What else do we run into when doing this? Obvious considerations: reading list population shouldn't hang because some other site is down. (AJAX updating, perhaps?)
In fact, any reference to another site should probably be as lazy as possible, both to avoid excess cross-site traffic and to handle sites being down gracefully and the like. Then again, we probably want to do that sort of thing anyway, to avoid excess local db traffic, so that shouldn't be too problematic.
The ability to refer to a LJ-codebase user as an Identity would also be very useful.
Note that external references may need authentication credentials associated with them!
Opinions? I do not need coders right this second, though of course I will at some point. And this only addresses the codebase and the technical issues of hosting and scalability, and not things like (for example), "Should the main site, or some member sites, be hosted outside of the U.S. for legal reasons?" or "What, if anything, is the pricing structure?" or many, many other administrative questions that still need to be answered.
I have been working on a Django-based replacement for LJ, something that is still heavily community-based the way LJ is, but with some improvements for some of the specific ways people have creatively used LJ. I went with Django for scalability reasons, and there are some design things specifically aimed at hosting an LJ-sized community. The effort's been sort of stalled for a while for a variety of reasons, but I still think it makes sense and I could certainly make some time for it.
Here's a collection of notes:
Basic Model:
- Account: represents a billing entity which pays (or doesn't) for service. Has at least one Identity, may have more than one.
- Identity: a posting identity, has Avatars (nee userpics), can make posts and comments. May have a single Journal.
- Do multiple journals in one identity make sense when you can have multiple identities? Examples each way might be good.
- Avatar: a small picture representing the user. Also called userpics, user icons, etc.
- Group: a collection of Identities. Has no other inherent meaning by itself.
- Journal: a collection of Entries. Has one Account which owns it. Has at least one Identity allowed to post to it.
- Entry: a single post in a Journal made by a particular Identity. Has threaded Comments associated with it.
- Comment: a single reply to either an Entry or another Comment made by a particular Identity.
- Community: a Group (members of the Community) and a shared Journal. The Account that owns the Community also owns the Journal and is the final administrator for the Community. Other Identities may have other rights (moderation, membership control, announcements, etc).
Yes, a Community is a small but significant extension of a Journal, mainly to provide membership management. By default everyone on the Members Group will be in the Posters Group of the shared Journal, but that's not required.
- Other possible model elements:
- Polls
- Voting/Rating
- Tags. I'm thinking this might be a decoration thing rather than a first class model element. I'm not sure yet.
- Memories. See Tags.
The default setup is something like an Account with a single Identity and a single Journal, with appropriate permissions. Obviously, though, this model allows many variants.
Other useful concepts:
Permissions:
Entries can have permissions on them saying who is allowed to read them. Public, Posting Account Only, Posting Identity Only, Reader Logged In and Group based permissions are all allowed. Permissions on an entry apply implicitly to the Comments in that entry.
Journals and Identities can have default permissions that will be used to post Entries in that Journal or by that Identity, respectively.
Question: Does it make sense to even try to have comment-level permissions? I suspect they'd be rarely used and more confusing than they're worth.
A Journal has a "Posters" Group which defines who's allowed to post to it.
A Community has a variety of permissions associated with it that will need their own Groups. Member management is the biggie here.
Question: Does Entry moderation live at the Journal level or the Community level?
Reading lists:
An Identity (I think this is the right level for this) can have one or more Groups associated with it as reading lists. By default there are two special groups, "Everyone" and "Default View". Adding anyone to any Identity's Group will also automatically add them to that Identity's "Everyone" Group.
Things to consider:
The "Everyone" group gives an easy way to do what LJ friends do now: add someone to your Default View and give them permission to read posts with "Everyone" permission. Of course, "Everyone" is tighter than "Reader Logged In" or "Public". Given that, "Everyone" may be the wrong name for it...
Should Accounts have this as well, so a given Identity's "Everyone" group would be the merge of that Identity's "Everyone" group and its Account's "Everyone" group, and so forth for other groups? I can see usefulness in this, but it might just confuse people too.
Groups should be able to include Identities from other sites running the same codebase. This would trivially let you have a multi-site reading list. (And, incidentally, multi-site Communities, also a bonus.) It seems pretty straightforward to me if we do Identities right.
Notification:
Obviously, we need a list of possible events about which a user can request to be notified, and a page for managing such stuff. And we actually need to do the notifications when they happen.
Miscellany:
- Recent activity? "RPG Console"...
Hardware Architecture:
The trick to this is scalability. We need to be able to host the site on a basic machine with everything colocated for getting started (and for smaller member sites) and we need to be able to run in a full multi-tier configuration, with database servers, memcached, separation of static and dynamic content, and so forth.
Django has a lot of potential here. RESTful architecture seems like a good principle for coexisting well with caching and the static/dynamic split.
Being fundamentally multi-site distributed will help with the scalability. I really like the idea that smaller subgroups can set up wherever they want and join the community and support most of their own load. (That said, a centralized site is probably useful to coordinate things and be the one that has all the caching set up well.)
Federated Community:
The simplest way to get this is for IDs to be global (e.g. by including the site name in the ID somehow). RESTful architecture suggests that everything is a URI anyway, so that might work well. We can still use numeric IDs locally; an unadorned numeric ID is obviously a local one.
What else do we run into when doing this? Obvious considerations: reading list population shouldn't hang because some other site is down. (AJAX updating, perhaps?)
In fact, any reference to another site should probably be as lazy as possible, both to avoid excess cross-site traffic and to handle sites being down gracefully and the like. Then again, we probably want to do that sort of thing anyway, to avoid excess local db traffic, so that shouldn't be too problematic.
The ability to refer to a LJ-codebase user as an Identity would also be very useful.
Note that external references may need authentication credentials associated with them!
Opinions? I do not need coders right this second, though of course I will at some point. And this only addresses the codebase and the technical issues of hosting and scalability, and not things like (for example), "Should the main site, or some member sites, be hosted outside of the U.S. for legal reasons?" or "What, if anything, is the pricing structure?" or many, many other administrative questions that still need to be answered.