possible ways to implement feed-channels (follow a channel, not a user):

1. use existing channel subscription messages: instead of subscribing to a
   channel name, subscribe to the message id of a channel message that someone else published.

2. use existing contact messages and separate feeds per user-channel. treat user-feed as separate social identities.

3. implement alt-feeds: make a new feed with the same keypair but different signing cap key. identify an alt-feed by public key + signing cap key. replicate it by public key + signing cap key + sequence number.

Meaning you'll start replicating strangers who joined the channel too, and you opt in/out for that by joining/leaving the channel.

i wasn't thinking of using channels as groups for replication, but that could be useful. how would you find out that a feed joined the channel/group, if you are not already replicating the feed?

in 1. i was imagining the channel that you subscribe to would be only messages by the author of that channel, to realize @Lenny's idea "In my hypothetical platform you simply can't follow people, you can just follow their channels". maybe it should be called something other than channel, since it would have this different semantic. this would be like a public one-way group.

@cel, "feed-channels", as you said, seems like a good name.

@Sybil, it's a simple idea, it's just named feeds, so that your friends can choose which "side" of you to follow. It doesn't have much to do with the current channels.

@ezdiy I'm open to alternatives, but I see it as a useful property that for me to get a message, there must be an explicit social path from my feed to the message author's feed, like with contact messages. To keep that property, a two-way group would be an add relationship - like follow but with the group as an explicit scope. Thus the identity which is fractal'd would be the network itself.

@ezdiy it sounds to me like the same challenge that the network as a whole has, ensuring message propogation, which is dealt with using contact and pub messages. if we apply that here, then the group members must follow eachother enough so that they fully replicate as a network. now, how about this: if group members follow eachother in the scope of the group, then the scoped follow can be the same as the group add. so, the type of group that i am describing would be equivalent to a replication scope. this would also allow for feed-channels: a feed-channel could be a feed that someone follows in a new/unique scope.

so, i am thinking now that being able to follow and replicate feeds in different scopes would be very useful, because it would allow for creating these alternative follow-graph networks (i want to call these something other than groups).

i am also thinking of if alt-feeds (namespaced signatures) could be useful for this purpose, and how/if scoped about messages relate to this, and what it would mean for a single feed to be followed in multiple scopes. it seems to be like these issues for scoped feeds could be addressed with the same approaches i described for feed-channels: either put all the scoped messages in the same feed (like with channels), or use a separate feed for each scope that a user wants to use (and perhaps use about-related messages to associate the user's various feeds), or use alt-feeds (namespace the signature with the scope id).