The more I think about this the clearer it becomes to me that Elgg's
friends are the equivalent of g+ circles. It's the terminology that is
confusing, but the design is sound. If we changed the terminology and made
friends collections more useful, people could treat different collections
as they please (e.g. easier to manage collection membership for a given
person, a page of activity from a particular collection). I would love to
have separate circles for the community site for "troublemakers" and
"potential core members" and be able to track the activities of each ;).
I would say that once you can share with just a certain subset of people
you circled, there is no need for "tight" friendship relationships.
Instead, you decide who to trust each time you post. How much you share is
what really determines the tightness.
Unless I'm missing something?
On Aug 23, 2012 2:53 PM, "Federico Mestrone" <fmestr...@gmail.com> wrote:
> Hi Steve,
> Thank for your reply. I have actually completed work on this now, using a
couple of plugins I found and adding my own code to implement the
ACCESS_FOLLOWERS level. Even so, I think this could really be a useful
improvement to the way that Elgg views user relationships out of the box,
so I'm still thinking of ways to refactor code to make it more useful to
> This would be my vision... ;-) Elgg Core would offer two types of
relationship between users
> 1) "friend": a bidirectional relationship between two users that requires
confirmation (same as Facebook atm, different to current Elgg
implementation). This is a close relationship between two users, hence the
need for confirmation on both sides (the one making the request, and the
one accepting it).
> 2) "follower": a one-way relationship from one user ("follower")
interested in more information about the activities of another user (that
they're "following") (same as the current implementation of Elgg friends).
This is a distant relationship... Anyone can follow whoever they like with
no need for the other party to confirm or accept the relationship.
> In terms of the access levels, in my implementation it leads to this, in
increasing order of breadth of scope
> ACCESS_PRIVATE (0) - only the owner
> ACCESS_FRIENDS (-2) - only the owner and friends (close relationship that
needs to be confirmed)
> ACCESS_FOLLOWERS (-3) - the owner, their friends, and all followers (who
can follow regardless of the will of the owner)
> ACCESS_LOGGED_IN (1) - everyone who is logged into Elgg
> ACCESS_PUBLIC (2) - everyone
> In between ACCESS_FRIENDS and ACCESS_FOLLOWERS currently sit the dynamic
> As far as UI goes, there is a number of changes that are needed, to allow
users to keep track of pending friends requests (before acceptance by the
other party) and the list of followers. But I have already assembled some
code from two existing plug-ins that do the job. The only thing plugins
cannot do is access the ACCESS_FOLLOWERS level without creating new access
> To crown it all, a number of settings would allow the admins to choose
how the new features should be used in their own installation. To avoid
confusion, for example, the basic installation should only enable followers
(exactly the same behaviour as the current version), with friends - in the
NEW sense of the word - available for enabling alongside followers or on
their own from the admin settings. Other options could be whether firends
should be included as part of the followers access level: in my case it is
and I think it makes sense, but there could be situations in which this is
> Anyway, I'll follow your suggestion and branch out of the core to make
the changes I have in mind. I think it's the best way for people to
evaluate whether it's a bunch of useful changes... and it's a great way for
me to learn more about this amazing platform ;-)
> On Thursday, August 23, 2012 9:09:53 PM UTC+1, Steve Clay wrote:
>> On 8/23/12 2:28 PM, Federico Mestrone wrote:
>> > I am working on an Elgg installation where we will provide both
>> > (reciprocal relationship requiring confirmation) and /follower/
>> > relationship, like the friends in Elgg Core).
>> Thanks for bringing this up in a careful and clear way. My first thought
is that this may
>> be a bit difficult for users to understand, but setting this aside for
>> ACCESS_FRIENDS in the core is really "people you have followed" and I
>> ACCESS_FOLLOWERS would be "people who are following you". I definitely
see some value in
>> the distinction. It's a bit like group-visible content in open groups
(to see the content,
>> just join the group).
>> Or would you use a completely separate access list so that reciprocating
>> not automatically be friends of each other?
>> > programmatically create an access collection for every user that is
being followed, though
>> > it seems that this is the only viable option in the API. Am I right?
>> This may actually be pretty easy: listen to relationship events for
following, and update
>> the followed user's access list.
>> > function in /engine/lib/access.php/. Clearly I'd rather stay away from
>> > core, but I think I don't really have a way around it.
>> As much as I rail on about not modifying the core, as long as your
development is firmly