Follow Hashtags #325

Open
opened 1 year ago by prologic · 10 comments
prologic commented 1 year ago
Owner

I'd like to propose a new feature for following #Hashtag(s).

Why?

One of the most frequent complaints I receive about how Twtxt works (but is also true of pretty much any social media platform) is you have to follow people in order to have a non-empty timeline. At Twtxt.net we have a general concept called Feeds where a user can own one or more Feeds and post as those "Personas" in addition to their own Username.

The problem is some people want to be able to post something, and see replies to that post (via Twt Subject Hashes) without having to follow those people.

How?

After thinking about this for a while, I realize that this could be generalised to just following Hashtag(s) in general. Meaning that we treat Hashtags as first-class citizens, like Users and Feeds. Hashtags would have their own "Followers" and users can follow any number of Hashtag(s) on a pod.

This could be extended to also pull the same set of Hashtag(s) from other known Pods too and aggregating tags across pods just like Conversations do today.

A side-effect of this feature would be that when an user initially posts a new Twt, they automatically become get subscribed to that Twt's Hashtag for any followup/replies to that Twt that form a Conversation. They can see this subscription in their profile like any other following and are free to "Unfollow" at any time.

It might be a good idea to periodically cleanup old/stale Twt Hash follows on pods across user accounts after a while as the likelihood of there being new replies over time become zero.

I'd like to propose a new feature for following #Hashtag(s). ## Why? One of the most frequent complaints I receive about how Twtxt works (_but is also true of pretty much any social media platform_) is you __have to__ follow people in order to have a non-empty timeline. At Twtxt.net we have a general concept called Feeds where a user can own one or more Feeds and post as those "Personas" in addition to their own Username. The problem is some people want to be able to post something, and see replies to that post (_via Twt Subject Hashes_) without having to follow those people. ## How? After thinking about this for a while, I realize that this could be generalised to just following Hashtag(s) in general. Meaning that we treat Hashtags as first-class citizens, like Users and Feeds. Hashtags would have their own "Followers" and users can follow any number of Hashtag(s) on a pod. This _could_ be extended to also pull the same set of Hashtag(s) from other known Pods too and aggregating tags across pods just like Conversations do today. A side-effect of this feature would be that when an user initially posts a new Twt, they automatically become get subscribed to that Twt's Hashtag for any followup/replies to that Twt that form a Conversation. They can see this subscription in their profile like any other following and are free to "Unfollow" at any time. It _might_ be a good idea to periodically cleanup old/stale Twt Hash follows on pods across user accounts after a while as the likelihood of there being new replies over time become zero.
Poster
Owner

To build this I am thinking:

  • Add a Tag model similar to Feed that has fields:
    • Tag -- The actual hashtag itself (including the # prefix)
    • Twt -- Whether this is part of a Twt Conversation, if non-empty the full Twt Hash (including the # prefix)
    • Followers -- A list of Twt URI(s) that follow this tag (both local or remote)
  • When.a user on a pod posts a new Twt a couple of things will happen:
    • A copy of that Twt will be appended to a matching twtxt.txt feed file in ./data/tags/<hash>, where <hash> is the OP's Twt Hash.
    • Any other tags in the Twt will also cause copies of the OP Twt to be mirrored to ./data/tags/<tag>.
  • A set of routes for the Web App will be added to serve up /tag/<tag> with a view similar to Feeds, where users can Follow/Unfollow that tag and see who else is also following that tag.
  • A route for the tag will also be available at /tag/<tag>/twtxt.txt that other users from other Pods or Twtxt users can subscribe to and follow.

The only problem with this approach is the twtxt spec/format itself. You loose the information about who posted a line of text in the file. That information is normally associated with the owner of that feed file in the first place, often identified by the Feed's URI. Conventionally a lot of users and clients will also place "metadata" at the top of the feed with key/value pairs like nick= and url=.

The only way the above would work is if we extended the twtxt.txt spec/format to also optionally include the "source" poster (somehow).

🤔

Feedback welcome!

To build this I am thinking: - Add a `Tag` model similar to `Feed` that has fields: - `Tag` -- The actual hashtag itself (_including the `#` prefix_) - `Twt` -- Whether this is part of a Twt Conversation, if non-empty the full Twt Hash (_including the `#` prefix_) - `Followers` -- A list of Twt URI(s) that follow this tag (_both local or remote_) - When.a user on a pod posts a new Twt a couple of things will happen: - A copy of that Twt will be appended to a matching `twtxt.txt` feed file in `./data/tags/<hash>`, where `<hash>` is the OP's Twt Hash. - Any other tags in the Twt will also cause copies of the OP Twt to be mirrored to `./data/tags/<tag>`. - A set of routes for the Web App will be added to serve up `/tag/<tag>` with a view similar to Feeds, where users can Follow/Unfollow that tag and see who else is also following that tag. - A route for the tag will also be available at `/tag/<tag>/twtxt.txt` that other users from other Pods or Twtxt users can subscribe to and follow. ---- > The only problem with this approach is the [twtxt](https://twtxt.readthedocs.org) spec/format itself. You loose the information about _who_ posted a line of text in the file. That information is normally associated with the owner of that feed file in the first place, often identified by the Feed's URI. Conventionally a lot of users and clients will also place "metadata" at the top of the feed with key/value pairs like `nick=` and `url=`. > > The _only_ way the above would work is if we extended the `twtxt.txt` spec/format to also optionally include the "source" poster (_somehow_). > > 🤔 Feedback welcome!
JonLundy commented 1 year ago (Migrated from github.com)
Poster
Owner

Just an off the wall option. What if we add it to the subject? Like just append something like this to each twt in the feed.

<date> (@<xuu ...> #<example ...>) this is an #example!

Just an off the wall option. What if we add it to the subject? Like just append something like this to each twt in the feed. `<date> (@<xuu ...> #<example ...>) this is an #example!`
Poster
Owner

Yeah I'm thinking that would work. Another option would be to shove some machine parsing data on the end of the line so subjects are backwards/forwards compatible

Yeah I'm thinking that would work. Another option would be to shove some machine parsing data on the end of the line so subjects are backwards/forwards compatible
lwojcik commented 1 year ago (Migrated from github.com)
Poster
Owner

Two loose thoughts without much consideration of implementation details, based on my experience with several social media websites long before Twitter and Facebook became de facto standards for this area:

  • hashtags are a great idea that works amazingly well as long as people who want to subscribe to them can do it easily even if they don't contribute content to them themselves (I should be able to lurk at the pod but never post anything). However, the other group of people who want to NOT see them anywhere for any reason, should be able to hit 'ignore' button and never see them anywhere in the pod they signed up for. I spend significant chunk of time moderating my Twitter timeline by adding / removing phrases in my block list (I rarely block individual accounts, in most cases I see no need for that). Being able to ignore certain hashtags helps me maintain healthy online relationships with other people even if our interests vary a lot. Being in charge of what I see in my timeline is what keeps social media interesting for me and I expect any other service to give me that sense of control.

  • I feel I should be able to post a twt and immediately unsubscribe from any replies to the content I just posted. While I can see room for abusing this feature, I believe this has potential of keeping some vulnerable groups of people active and encourage them to post unpopular, but important things.

I'll post more if anything comes to my mind.

Two loose thoughts without much consideration of implementation details, based on my experience with several social media websites long before Twitter and Facebook became de facto standards for this area: * hashtags are a great idea that works amazingly well as long as people who want to subscribe to them can do it easily even if they don't contribute content to them themselves (I should be able to lurk at the pod but never post anything). However, the other group of people who want to NOT see them anywhere for any reason, should be able to **hit 'ignore' button and never see them anywhere in the pod they signed up for**. I spend significant chunk of time moderating my Twitter timeline by adding / removing phrases in my block list (I rarely block individual accounts, in most cases I see no need for that). Being able to ignore certain hashtags helps me maintain healthy online relationships with other people even if our interests vary a lot. Being in charge of what I see in my timeline is what keeps social media interesting for me and I expect any other service to give me that sense of control. * I feel I should be able to post a twt and immediately unsubscribe from any replies to the content I just posted. While I can see room for abusing this feature, I believe this has potential of keeping some vulnerable groups of people active and encourage them to post unpopular, but important things. I'll post more if anything comes to my mind.
Poster
Owner

@lwojcik Can you elaborate on your 2nd point a bit more?

@lwojcik Can you elaborate on your 2nd point a bit more?
JonLundy commented 1 year ago (Migrated from github.com)
Poster
Owner

@lwojcik Can you elaborate on your 2nd point a bit more?

Something in Twitter is where you can prevent non-follow users from replying to you. In accounts that have many thousands of followers can get an avalanche of replies. I believe what he means is if they post something that may be unpoplar they wouldn't want that avalanche on opposing view replies. Can be a bit detrimental to ones well-being :)

> @lwojcik Can you elaborate on your 2nd point a bit more? Something in Twitter is where you can prevent non-follow users from replying to you. In accounts that have many thousands of followers can get an avalanche of replies. I believe what he means is if they post something that may be unpoplar they wouldn't want that avalanche on opposing view replies. Can be a bit detrimental to ones well-being :)
JonLundy commented 1 year ago (Migrated from github.com)
Poster
Owner

I had thoughts about having some out of band area to put info. like say privacy settings that would prevent twts from being replicated off pod. or outside a group of mutual follows. like a third column that is stored locally in a third column.. but when the twtxt.txt file is requested gets stripped out.

I had thoughts about having some out of band area to put info. like say privacy settings that would prevent twts from being replicated off pod. or outside a group of mutual follows. like a third column that is stored locally in a third column.. but when the twtxt.txt file is requested gets stripped out.
Poster
Owner

@lwojcik Can you elaborate on your 2nd point a bit more?

Something in Twitter is where you can prevent non-follow users from replying to you. In accounts that have many thousands of followers can get an avalanche of replies. I believe what he means is if they post something that may be unpoplar they wouldn't want that avalanche on opposing view replies. Can be a bit detrimental to ones well-being :)

I see.... This type of "abuse" (as I see it sort of, social abuse if you will...) is kind of much harder to achieve with Twxt being a pull-only model and decentralised. The "Avalanche" effect would be quite hard to do across pods, but I see the point.

If I'm interpreter this as a "requirement" would this basically be some kind of checkbox on your post that says something like "Subscribe to replies?"

> > @lwojcik Can you elaborate on your 2nd point a bit more? > > Something in Twitter is where you can prevent non-follow users from replying to you. In accounts that have many thousands of followers can get an avalanche of replies. I believe what he means is if they post something that may be unpoplar they wouldn't want that avalanche on opposing view replies. Can be a bit detrimental to ones well-being :) I see.... This type of "abuse" (_as I see it sort of, social abuse if you will..._) is kind of much harder to achieve with Twxt being a pull-only model and decentralised. The "Avalanche" effect would be quite hard to do across pods, but I see the point. If I'm interpreter this as a "requirement" would this basically be some kind of checkbox on your post that says something like "Subscribe to replies?"
Poster
Owner

I had thoughts about having some out of band area to put info. like say privacy settings that would prevent twts from being replicated off pod. or outside a group of mutual follows. like a third column that is stored locally in a third column.. but when the twtxt.txt file is requested gets stripped out.

Ooooh that's a bit interesting... Are you thinking about limiting what Twts of yours get mirrored to other Pods in some way? They do so now across conversations because of some property of the Twt Hash Addressing I admittedly don't really understand, but it works :) (it feels like magic™ :P)

Is this what you mean? Or something else? I've always thought that if you put up a blog that you're basically publishing it for the world to read. Same idea goes for micro blogging in my opinion, and thus Twt(s). The "privacy" aspect for me as been "how much does the system know about me", "what can others directly infer or extract from my profile", etc. The only two knobs that exist today for users are "Show me followers publically" and "Show me followings publically". The only global pod level knobs at the moment are "Open/Close profiles".

> I had thoughts about having some out of band area to put info. like say privacy settings that would prevent twts from being replicated off pod. or outside a group of mutual follows. like a third column that is stored locally in a third column.. but when the twtxt.txt file is requested gets stripped out. Ooooh that's a bit interesting... Are you thinking about limiting what Twts of yours get mirrored to other Pods in some way? They do so now across conversations because of some property of the Twt Hash Addressing I admittedly don't really understand, but it works :) (_it feels like magic™ :P_) Is this what you mean? Or something else? I've _always_ thought that if you put up a blog that you're basically publishing it for the world to read. Same idea goes for micro blogging in my opinion, and thus Twt(s). The "privacy" aspect for me as been "how much does the system know about me", "what can others directly infer or extract from my profile", etc. The only two knobs that exist today for users are "Show me followers publically" and "Show me followings publically". The only global pod level knobs at the moment are "Open/Close profiles".
github-actions[bot] commented 11 months ago (Migrated from github.com)
Poster
Owner

This Issue has gone stale and will be closed automatically.

If this is incorrect, please reopen and add the label on hold.

Thank you.

This Issue has gone stale and will be closed automatically. If this is incorrect, please reopen and add the label `on hold`. Thank you.
Sign in to join this conversation.
Loading…
There is no content yet.