New Messages for multi-feed devices

These are some messages I want to add to allow other apps (like ferment) that use their own feeds to integrate better into the existing scuttleverse.

about: related: {[scope1]: [...ids], ...}

This is used to announce that a feed has related feeds. For example, if this is a "patchwork" feed, it can be announced that the same person also has a "ferment" feed:

{ type: 'about', about: '@feedId', related: {ferment: ['@relatedFeedId']} }

This message can be used by other applications (such as ferment) to allow the user to discover other friends that also use this app (from a different feed than their master) and add them.

about: scope: 'scopeName' or scope: [...scopeNames]

Used to announce that a given feed has a particular use. Apps can then choose to ignore this feed and not display it in the interface. For example, Ferment would hide all non-ferment feeds from suggestions, etc.

contact: scope: 'scopeName' or scope: [...scopeNames]

Allows creation of replication boundaries. This allows a pub or user to follow someone as a particular scope. Others apps won't cross this boundary if they have a scope specified in their ssb-friends config.

(this obviously requires changes to be made to ssb-friends)

@mmckegg with a message like {type: 'contact', scope: 'scopeName', following: true}, wouldn't current clients ignore the scope property and treat it as an unscoped follow? people creating this messages might have new clients, but their followers and followers' followers might not, and so those followers might end up replicating feeds that they weren't meant to replicate. would it be better to use a different property for following, like scopedFollowing, or a different message type, like scoped-contact? then old clients would use the correct behavior and not replicate feeds followed in a scope.

@cel interesting point! I will give this some thought.

My original thinking was that if someone wants to cut down on replication, then they choose which scopes they want to replicate. And some clients will do this by default. If someone was using an older client, replicating extra stuff would be their own problem.

Also, older pubs will still replicate scoped feeds (which IMO is good!)

@mmckegg ok, that makes sense.

i think scoped replication could be useful as a general-purpose way to have multiple follow-graphs: %5/1IDH5.... if scuttlebot could replicate in multiple scopes, then choosing to replicate a scope could be done just by following, in that scope, some feed(s). then you would replicate their followees and followee's followees, etc, according to the configured hop count, in that scope.

good point about old pubs replicating scopes. a scope should probably not rely on this too much, otherwise users might suddenly find they can't replicate anymore if all their pubs switched to replicating only some other scope(s).

also, the invite.use method should take a scope as an option, so that when you use an invite, you can tell the pub which scope to follow you in. maybe pub messages should have a scope property too, so that peers could better decide which pubs to connect to.

what if it was following: scope and boolean means "everything" maybe it could also be an array if you follow them in multiple scopes? or an {} object.

I'm mainly interested in keeping the follow graph datastructure as elegant as is feasible.

@dominic yes, that makes sense, to allow for following (or blocking) in multiple scopes at once

of course, from a client perspective, it is easiest to a render a message when it is just one thing (vs like in about messages where many things could happen). but it is good to build on existing usage

Yeah, this makes sense to me.

Also solves the last point on: https://github.com/ssbc/ssb-contacts/issues/1#issuecomment-310969132

scuttlebot/test/friends.js uses blocking: {reason: string} which could conflict with blocking: {<scope>: boolean} - but that part of the test is mostly commented out, and i don't have any messages that use reason in that format, and none of the clients generate such messages, so i don't think it is a problem. we could put reason in content and consider it to apply to the message as a whole

I was thinking about this again, it might be better to make the format be {<scope>: {<follower>:{<followed>: boolean}}

Then an implementation could choose to index a scope or not, and I feel it follows more closely to the concept of scopes too. You could easily do a query that totally ignores a scope, or is restricted to a specific scope.

{<scope>: {<follower>:{<followed>: boolean}}

to clarify, would follower be the target feed id (instead of the contact property?)
and would followed be the relation type (following, blocking, flagged)?

if so, this would allow for using {reason: string} or other arbitrary truthy data for the boolean value, which could be useful.
it would also allow for relating to multiple contacts in one message, which seems okay to me.
it would also break backwards compatibility so would be ignored by existing sbots. this would be useful if you want that: %ezEUduX... or not useful if you don't want that: %UfwxBAq...

including scope in the object path before the feed id and relation type makes it required. what would we use for scope if want to have continuity with the current scope which is none/all?

@cel on a contact message, the "follower" is the feed which performed the following action. to be more explicit, it might be:

{
  <value.content.scope || "default">:{
    <value.author>:{
      <value.content.contact>:<value.content.following>
    }
  }
}

@dominic when would it be useful to publish a message with follower other than the message author?

that would be like following for someone else, you can't do that, you can only declare your own follows.