Side-effects of a "follow" activity

[evanp]

If user A follows user B, there should be about 4 changes to the state of the world:

1. User "A" should be added to user B's "followers" collection.
2. User "B" should be added to user A's "following" collection.
3. A "follow" activity should be added to user A's recent activities stream.
4. The same "follow" activity should be added to user B's inbox.

Whose responsibility is it to handle these additions in SoLiD?

[elf-pavlik]

This reference may help to understand "followers" and "following" collection and proposed properties (link relations) relating them to agent (owner)

• http://w3c-social.github.io/activitypump/#collections
• http://w3c-social.github.io/activitypump/#actor-objects

[evanp]

They're also referenced in many of the use cases.

Evan Prodromou

On May 3, 2015, at 10:42 AM, ☮ elf Pavlik ☮ [email protected] wrote:

This reference may help to understand "followers" and "following" collection and proposed properties (link relations) relating them to agent (owner)

http://w3c-social.github.io/activitypump/#collections http://w3c-social.github.io/activitypump/#actor-objects — Reply to this email directly or view it on GitHub.

[deiu]

It will be the client's responsibility -- i.e. whichever app the user goes through to browse and manage their social graph.

[bblfish]

I can imagine following someone and not wanting to notify them I am doing that. So I don't think point 1 user A being added to user B's following collection is immediately necessitated by A following B. A can follow B by just adding a link to one of his groups. Of course that will mean he'll have to do pulls to find out about changes on B's public feed.

What is required if A wants to be notified of changes to B, is then for A to subscribe to some changes on some resources. That would require a generic notification protocol on some resource to be developed. Say A wants to be notified about changes to B's blogs entries on a certain topic, then he could send such a request to the relevant resource. Perhaps to receive all public changes that would require subscribing to the activity stream. The server there would be an agent that would then notify A's chosen notification inbox, which would just an LDPC that took certain types of notification messages - perhaps activity stream items.

We have an example of client based sharing where it made sense in a one to one scenario for Ian's client who made the resource to also notify Jan. The client could of course go through a third party that would have a responsibility to notify someone else.

Wether that third party is a server or a client should not matter. What needs to be clear is when one is doing it directly, and when another agent is doing it for one.

The advantage of @deiu 's thin server approach is that it is allows one to create very standardised and non domain specific servers. It would be good to be able to stay as generic as possible on the server, so that the social web can grow without new APIs needing to be invented for every type of communication activity.

[evanp]

So, there won't be a way to keep a list of followers in SoLiD? This is a pretty core feature, and it's pretty important for doing distribution.

I'm realizing that when you do a "follow" action with SoLiD, since you're using FoaF, that's just updating the main FoaF document with a "knows" property or something similar.

So you don't plan to keep a separate collection or other resource for the lists of followers, following, and friends?

[sandhawke]

On May 9, 2015 3:36:05 PM EDT, Evan Prodromou [email protected] wrote:

So, there won't be a way to keep a list of followers in SoLiD?

I'm not sure I understood Henry's post, but I think he's talking about hypothetical designs and concerns and possibilities.

Cimba does have a list (container) of followings. Alice is responsible for storing that Alice followers Bob. She can decide whether to make that fact public, or just show Bob, or keep it to herself as she likes. (It's just a data page on her site.)

This is

a pretty core feature, and it's pretty important for doing distribution.

In this design, following is used to (1) tell the world a sort of endorsement, and (2) tell your reader software which feeds you want to see.

An actual data-subscription mechanism affecting data flow, e.g. PuSH, is seen as independent and private, and not yet implemented to my knowledge.

This is probably the point to apologize for SoLiD not being as fully defined ("solid") as one would like for this conversation.

I'm realizing that when you do a "follow" action with SoLiD, since you're using FoaF, that's just updating the main FoaF document with a "knows" property or something similar.

So you don't plan to keep a separate collection or other resource for the lists of followers, following, and friends?

No, we do.

---

Reply to this email directly or view it on GitHub: https://github.com/linkeddata/SoLiD/issues/16#issuecomment-100535209

[bblfish]

@evanp foaf also has a notion of groups. So you can have a number of different groups, such as those people you follow, those people who follow you, the members of the Social Web WG, your family, etc... Some of these groups can be maintainedby other organisations ( eg the Social Web WG members would be maintained by W3C) All of those are really useful for building access control rules on resources.

Now the Web Access Control agent is of course a server agent, that can fetch information from the web to make his decisions. So the server can be active. And it seems reasonable that it should notify other resource too. I think file systems have this capability so why not LDP.

[elf-pavlik]

I don't see using container excluding using direct relations e.g. follows I also try to look for a way to avoid creating 4 properties/predicates for each type of relation following, follower, followings, followers and instead use reverse + ldp:DirectContainer / ldp:IndirectContainer or hydra:Collection this way managing everything with single property / predicate follows (seeAlso: https://github.com/w3c-social/social-vocab)