Peter,
Perhaps I'm not understanding what you're saying, exactly, but I think
much of what you're suggesting is already part of the way Laconica
works. For instance, your notion of a "community" is equivalent to a
Laconica instance. Identi.ca is one such "community," army.twit.tv is
another, and so forth. As a messaging system, I think Laconica's use
in an Enterprise would actually be to administer more than one
Laconica instance and as a result our development should focus more on
the ease of maintainability for sysadmins who need to do this rather
than writing code to link up or segregate "communities" with one
another inside of a single Laconica instance.
Hope this makes sense…?
All that being said, this also strikes me as somewhat tangential to
the notion of groups versus tags. A great explanation of the
distinction (on top of the one provided by Evan) here is at http://laconi.ca/trac/ticket/1153#comment
:19.
• A group is a collection of people and addressable as that
collection (all people at once)
• a tag is an attribute that can be attached to dents (hash tags)
and to people (people tags for subscriptions and subscribers, self-
tags for yourself)
I guess another way to think of it is that a group is like an email's
BCC header. You can't use tags there…it wouldn't make any sense. The
conflation of groups *that have the same name as a tag* is the only
point of contention, but I believe that contention is actually caused
by the strict 140 character notice length limit, and *that* is what
"banghashes" were trying to address.
Cheers,
-Meitar Moscovitz
Personal: http://maymay.net
Professional: http://MeitarMoscovitz.com
P.S. Sorry for the tardy reply. I was on a trip sans-Internet for a
few days. I'm back(-ish) now. :)
On Feb 9, 2009, at 8:23 AM, Peter H. Reiser wrote:
Maybe we should view this from a social networking/collaboration
point of view.
Over the last few year we developed a model called Load-Link-Share-
(Restrict)
For Laconica this means:
Load = a user post a notice
Link = #tag the notice to link it to related notices (and other
content using this tag)
Share = Share it with Communities and/or people
Restrict = restrict read/write/ admin ACL to groups and/or people
As you can see - we make a difference between a
Group = a collection of people used to apply ACL's
and
Communities = collection of groups and individual people
This model allow to apply any access control granularity needs you
might have
Example:
A community named laconica (id =:laconica) consists of
- Core member group with read and write ACL within their community
(group id = !laconica-MEMBERS)
- Group reviewer belongs to the community but only has read ACL
( group id = !laconica--Reviewers)
- Joe and Jim are individuals and have admin rights to administrate
the group (user name:@joe,@ jim)
In our implementation we have following tagging policy
Community tag = community:uniqueCommunityKey laconica
= :uniqueCommunityKey
Core Member group of a community = MEMBERS-uniqueCommunityKey
laconica =!uniqueCommunityKey
Associated groups: either uniqueCommunityKey-GroupName for related
groups managed by this community (laconica - !!uniqueCommunityKey-
GroupName or any other group name e.g. all-identi.ca-users
The beauty on this model is to
Plus
+ relates notices (and other content) via Tags
+ share with communities via Community Tag (in laconica it could
be :community)
+ granular ACL if needed based on groups e.g !Laconica or !
Laconica-Reviewers and individuals e.g @Jim
+ works across multiple laconica instances (and other social
services using the same convention)
Minus
- need explanation about the difference of a groups and communities
- need to enforce name conventions for groups .
- need to add Community identifier e.g :
- more complex than a simple group model.
Summary
@xxx = user
#xxx = tag
!xxx = group
:!xxx =community
:!xxx could consist of @xxx(admin), !xxx*read/write), !yyy(read)
If you are interested you can watch a short video which show how
we implemented the LLS model https://slx.sun.com/1179273037
for attachment sharing ...
Maybe this looks pretty complicated .. but this model satisfies the
main enterprise needs for open-secure social collaboration :-)
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev
