An interesting thought experiment

Mon, 25 Mar 2019 16:10:04 -0300

M. Dent

dm42@hub.webgoeslocal.net

!Hubzilla Advocacy

I think this could be an interesting angle for Hubzilla -

Hubzilla as EMAIL 2.0:
* Fusion of the "best of" email/social media
* familiar "social media feed" structure
* establish "friendships" and follow persons of interest
* Fixes Email's "Spam" problem (friendships must be "accepted" before messages will be recieved)
* Fixes "Social Media" algorithm problems - you choose what you see and from whom - and when (with stream filtering and affinity slider enabled)
* Fixes "Social Media" bot/troll problem - you choose who sees what and who can comment and interact with what.

There's only ONE feature that I really really want - (I've mentioned it before and it is next on my "hit list" after my current project is wrapped up) and that's the ability to create a PUBLIC post that is directed to a subset of my connections. I think it can best be described as similar to having several mailing lists run from a single channel. I want the posts to be considered "PUBLIC" - to allow recipients to share and redistribute them and direct other people to them (so, "privacy groups" is not the right solution) but I do not want them broadcast directly to ALL of my contacts. I'd like my contacts to be able to choose which "subchannels" they receive - and maybe even I'd like to be able to set the defaults for new connections or for those who haven't configured which "subchannels" they want to receive.

The idea is to create a way that people who aren't interested in my POLITICAL discussions or my RELIGIOUS posts don't have to see them if they don't want to just to see my posts about Hubzilla --- (or, you know, my cat pictures). At the same time, I don't want to have to create multiple channels/identities and keep close track on where I am all the time just to avoid cluttering up other people's newsfeeds.

NYT | Switching to a New Social Network That Isn't Really New at All

SAN FRANCISCO — My favorite new social network doesn’t incessantly spam me with notifications. When I post, I’m not bombarded with @mentions from bots and trolls. And after I use it, I don’t worry about ads following me around the web.

show all 18 comments

Mon, 25 Mar 2019 16:25:28 -0300

Mario Vavti

mario@hub.somaton.com

@M. Dent it's not the same as you describe, but if you create a public forum and invite a group of peaople to join it, you could basically achieve a similar situation. The plus side would be that not you decide who want's to see your cat pics but the people joining the forum.

Mon, 25 Mar 2019 17:09:41 -0300

M. Dent

dm42@hub.webgoeslocal.net

And a good point! In many cases, that can work quite well and is a great solution.

There are some other use cases that I have need for where that doesn't fit so well.

The interface I have in mind allows both sides to make the determination - if the "recipient" hasn't set any preferences, the "sender" can set some defaults.

I had a setup I was happy with in 3.8, but it worked based on some ambiguities in the Zot spec that got cleared up in Zot6 (in a way that "broke" my solution - unfortunately). Oh well... "back to the drawing board".

Tue, 26 Mar 2019 05:46:14 -0300

Malendur

malendur@ussr.win

Remember that if Hubzilla aspire to become the new Email, its protocol should be a standard (and there are still lot of work about that) adopted by other apps. Without this standardization, Hubzilla will settle to be <another-isolated-messenger> 2.0.

Tue, 26 Mar 2019 06:36:31 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

I think the proper concept is already in place: categories. If other channels were able to condition 'send stream' permission on a category list, then on delivery you would match the post's categories list with the channel's subscriptions and only push if they match.

I'm pretty sure this can be achieved with an add-on if you're ok with the person having to visit your channel to set up her preferences.

Channels fetching your feed for content would also need to be handled somehow. Does zot6 still do this? I don't like the idea of providing a partial list when someone fetches your stuff so this would require an add-on on the receiving side as well.

It could get more complicated with post updates because we might want to update a post we delivered even if it is no longer in the subscribed categories, but it might just not be worth the effort. Then the semantics would be if you leave a category you also leave updates.

Tue, 26 Mar 2019 08:17:07 -0300

M. Dent

dm42@hub.webgoeslocal.net

@Alexandre Hannud Abdo - you are actually not far from the solution I've decided on. But conditional 'push' is a no-go in the way it needs to work for this structure. You cannot 'conditional push' and make a post public at the same time. If you specify recipients in the envelope, it is automatically a private posts. If you don't specify recipients, anyone on a hub that has "can post to my stream" set for a sender will receive the post if that post is received by that hub.

That wasn't fully specified or at least wasn't enforced in Hubzilla prior to 4.0. so a sort of "conditional push of public posts" used to be possible. It is fully specified and enforced in 4.0/Zot6.

That said, using categories may be able to be made to "fit" the solution in other ways. Thanks for the tip! I need to think through the UI considerations.

Tue, 26 Mar 2019 08:25:36 -0300

M. Dent

dm42@hub.webgoeslocal.net

@Malendur - It was a conceptual description, maybe better said, a way to frame the conversation about the value prospect of Hubzilla/Zap/ZotPlatforms. It wasn't a technical description or "aspiration" of the platform nor was it a protocol discussion. It was purely a functional description.

Tue, 26 Mar 2019 19:03:36 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

Right, message delivery is done on a "to hub" basis, so no easy way to filter what we expose based on the channel.

This means that the addon must be installed on the receiving end. It must also be installed on the sender, to keep synced the categories that are being received by a contact, for sender awareness but also in case of changes to the categories.

There should also be a convenient and sure way to deliver a post to all your followers. I.e. having a special "broadcast" category. This would allow one to properly categorize a post while at the same time making sure everyone gets it. It would also allow an additional "subscribe to posts with no categories" option.

Finally, messages citing the receiver should also get through regardless of category subscription.

Tue, 26 Mar 2019 19:22:01 -0300

M. Dent

dm42@hub.webgoeslocal.net

Exactly. My original plan was to basically create a separate taxonomy - but I kind of like the idea of using categories in this way. Maybe part of the interface on the sender side is to designate "subscribeable" categories as opposed to just general categories - or maybe that's going too far?

Good point about the "all followers" broadcast.

My thought on the receiver side is to store the subscription stuff in abconfig and creating a mini structure for it to allow a little more granular decision making and more info to be communicated (for example a longer description could be given by the sender about what type of content would be included in that category). Then add a "category subscriptions" section to the connection settings page.

I hesitate a bit to do so, but based on this model, it is also possible to create a "hashtag subscription" subsystem for public posts to be added to a channel network feed - replies generally would not be possible - but it would sort of fulfill a long standing desire for content discovery tools....

Tue, 26 Mar 2019 20:08:03 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

I think one should really stick to the basics on this.

The semantics is that of subscription: we're working with boundaries defined by the sender, chosen by the receiver, while informing the sender so they know who is subscribed to which categories.

So this is different from filtering, which one may want to make more granular. I also think the complexity of subscribeableXnon-subscribeable categories is not worth it. And although having a description associated with categories can be useful if well employed, I wouldn't say it is of primary importance since a category's name and content arguably already do the job well.

As for hashtags, they have different semantics, and content discovery is a different business.

A parallel but more pertinent issue is how categories cross with privacy groups and privileged access: at some point one would like to have some categories only shown to people in certain privacy groups. I.e. so that only people in one's family know that they have a category "living with my chronic disease". This is independent from the current discussion and IMO is not an addon thing: category visibility access control should be in core.

Tue, 26 Mar 2019 20:56:58 -0300

M. Dent

dm42@hub.webgoeslocal.net

while informing the sender so they know who is subscribed to which categories.

I don't know that this would be an outright requirement, but I do think it would be helpful - at least being able to have a sender set some sort of "default category subscriptions" that could then be overridden by the receiver if desired. The ability for the sender hub to know which receivers are subscribed to which categories would, however aid in efficiency of notifications and deliveries. No reason to send to a hub if nobody on that hub wants the message.

Re:category visibility - that's an interesting point and conceptually not too difficult. Implementation and UI may be a bit of another issue... But maybe not.

Re: subscribeability - ultimately, I think you're right. Though, I was more or less thinking of it as a way for the sender to flag "these are the categories I'm using for audience determination". Maybe the answer is to let that happen organically with senders putting that info into the category name itself "Audience:Politics" for instance. That would certainly simplify the logic.

Wed, 27 Mar 2019 10:30:51 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

I say juste leave it to the reader to pick what he considers a useful category given its name and what has been published. And the sender should definitely be aware of who's subscribing to which categories. Information on who's subscribing is implicit in the semantics of subscription and is important for it to work, not techincally but in action. And the default should simply be to subscribe to the full channel, thus to all categories. This is about giving the reader some choice where a priori the sender wants them to get everything - otherwise he'd be using privacy groups - but he's letting readers decide what they get.

Wed, 27 Mar 2019 11:30:37 -0300

Mario Vavti

mario@hub.somaton.com

The receiver already has the possibility to filter posts based on content (Connection Filtering). If you agree on some tags you use, the receiver can easily decide which posts to import and which not...

Wed, 27 Mar 2019 13:19:25 -0300

Michael

mike@narrow.world

(I somehow "disliked" this post by accident. Oops!)

Wed, 27 Mar 2019 13:20:43 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

Sure, @Mario Vavti , but what category subscriptions could achieve is to make practical this task of "agreeing on tags" plus retaining the semantics of subscription which is important for the sender to evaluate the consumption of his content.

In practice this is very different from connection filtering.

Wed, 27 Mar 2019 17:23:49 -0300

Beni Grind

navigium@grindcore.ch

Today I read an article in this weeks edition of The Economist where they explain how to fix social networking. It was mostly a description of Hubzilla without mentioning it by name.... decentralized, you decide who sees what, being able to take your friends/contacts with you to another provider....

Wed, 27 Mar 2019 18:00:19 -0300

M. Dent

dm42@hub.webgoeslocal.net

@Beni Grind - Link? Is the article online?

Thu, 28 Mar 2019 03:10:47 -0300

Beni Grind

navigium@grindcore.ch

I'm not sure whether you're are able to open this link without a subscription:

https://www.economist.com/leaders/2019/03/23/why-big-tech-should-fear-europe

I'm mainly talking about this part:

The next step is to allow interoperability between services, so that users can easily switch between providers, shifting to firms that offer better financial terms or treat customers more ethically. (Imagine if you could move all your friends and posts to Acebook, a firm with higher privacy standards than Facebook and which gave you a cut of its advertising revenues.)

Sat, 30 Mar 2019 04:56:49 -0300

Martin G.

marting@emgee.longmusic.com

@Beni Grind Could you send them an e-mail or so and tell them that what they wish for exists already, and it's called Hubzilla? Because some more publicity via widespread media is always good.