Hi Evan, Great to hear that groups are just around the corner !!!
Here some thoughts of the bleeper.de team: reg. 3. We suggest that groups and users should share the same name space to avoid confusion for the reader (even if it limits the available names) reg. 5. Just a question: What about sending updates to a remote subscribed group? reg. 9. We would also prefer the !groupname syntax (even if this might be more difficult to understand for not so experienced micro-blogger at the first look, but it clearly helps to differentiate) reg.11. Block and admin approval are quite important, on a short term we would say that block should have high priority (as a kind of reactive measure for the group admin) reg. 12. Renaming the @sender to the !groupname of a posted update sounds good. We would recommend to add the sender info to the meta-data (e.g. from @sender) Hope these comments are helpful to you ! See you in Hamburg at MBC09 ! Best regards, Ralf bleeper.de 2009/1/17 Evan Prodromou <[email protected]>: > Hi, folks. I'm hoping to roll out a first version of 'group' functionality > for next week's release (just before MBC09). I'd love to confirm some design > decisions with you before I do. > > If you are a member of a group, you can direct a notice to a group, and the > group will echo that notice so that everyone else in the group receives it. > (Groups work more or less like mailing lists in email.) > Groups have nicknames, just like users, with the same restrictions on chars > and length. > Group nicknames are in a different namespace from users. So, there can be a > user 'ubuntu' and a group 'ubuntu' on the same server. Alternative: groups > and users share a single namespace. This makes addressing more consistent > (see below), but means that we lose all the 'squatted' nicknames on > Identi.ca (we can't have an 'ubuntu' group, since 'http://identi.ca/ubuntu' > already exists), or we have to forcibly seize squatted nicknames. Neither is > very nice. > Groups have profiles, more or less like users. They have profile data > (fullname, homepage, bio, location, avatar/logo), a profile URL (like > http://example.com/group/groupname), and a permanent URL > (http://example.com/group/id/13). > Remote users can subscribe to group feeds, just like they subscribe to user > feeds. The OMB 0.1 protocol can handle this just fine. Maybe in OMB 0.2 > we'll add some extra metadata, like 'omb_this_is_a_group'. > There will be a list of group memberships on your profile page. > There will be a list of members on a group profile page. > Every group has one or more administrators who can modify the group > parameters. > We'll use a separate syntax for directing a notice to the attention of a > group. I think that '!groupname hey everyone' is probably good; I believe > it's what Plurk uses. Alternative: we use '@groupname hey everyone', and the > software guesses whether you're talking to a user or a group (based on your > subscriptions). The general feeling around here is that guessing is bad. > Alternative: if groupnames and usernames are in the same namespace (see 3 > above), then we can use @groupname for everything and it won't matter. (This > works more like email, where you use the same kind of address for lists and > for individuals.) > Notices directed to groups by non-members will be ignored. > Anyone can join a group (first implementation). We may have a flag that lets > admins' approval be required for later implementations; we might also > include a 'block' feature here. > Notices echoed by the group will look like the group is the author. If user > 'fred' send '!groupname hey everyone', the notice will be resent with the > author='groupname', and have the text: '♺ @fred hey everyone'. Alternative: > the author looks like fred, and there is some extra metadata that says the > notice is 'via' the group. > Groups do not do anything with direct messages ('d messages', 'dms'). > Groups will have a list of 'related groups' (defined by the admin) on their > profile page. > > Feelings, emotions, opinions, furious denouncements? > > -Evan > > > _______________________________________________ > Laconica-dev mailing list > [email protected] > http://mail.laconi.ca/mailman/listinfo/laconica-dev > > _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
