First, to meet the demand for hashtags-qua-'hashtags', match what people know from elsewhere, warts-and-all.
Just as on the web, where "users spend most of their time on other sites", Bluesky users will have learned most of what they know about hashtagging from other systems, and indeed even do most of their hashtagging on other systems.
So to the extent the behavior is called 'hashtags', & involves short slugs started with #, perhaps with autocomplete suggestions, that then become reader-clickable links (either at compose time or later), less surprise for users is best.
Classic hashtags will span across networks, just as they've invaded older non-hypertextual media like billboards & print ads. And, to the extent multinetwork clients & crossposting tools arrive for open systems, minimal classic hashtags have immense inertia as a familiar, lowest-common-denominator folksonomy & discovery tool. (Composing a post with classic hashtags once, posting to many varied systems, should still be kinda easy and useful.
So, don't hold up the boring-but-necessary work of providing the usual baseline while other more-bluesky/greenfield possibilities are discussed/designed. Just get working…
minimal autosuggest (with caveats below)
autolinking of hashtags (to some locally configured, subject-to-change 'explore tag' functionality)
…then declare victory on 'hashtags' to focus on next-level stuff (per below).
Regarding autosuggest, running a central service brings offensive-token-policing complexity & costs - so a safer initial course would be to:
populate autosuggest options only with tags seen in the user's own opted-in feeds/visible-posts, and
let them 1-click 'forget' or [perma-]'hide' any individual unwanted tags from the autosuggest dropdowns, and
let them turn off autocomplete entirely if they need to.
Then, autosuggest only shows things they could have seen (or even did see) elsewhere in their client. Curating their feeds is the same as curating their autosuggest, & (if all else fails) they can turn off unwanted term risks entirely.
Similarly, the safest initial contents of an "explore #tag" page would be occurrences of that tag from only the user's existing chosen feeds/viewable-posts – with options (perhaps sticky with user choice) to visit offsite searches/support-feeds/etc.
That then gives space for the other prong...
Second, pursue breakthrough better-than-hashtagging functionality, under some distinct new name, to avoid encumbering the new with old syntax- and expectations- interference.
In scope here would be new mechanisms/syntaxes/behaviors for:
tags in a separate field outside the main inline text
more formalized directives requesting inclusion/exclusion from certain presentations, or how multiple stacked tags should be interpreted
disambiguation when short-names collide, via some inner unique-id or even descriptor-doc – or delegated tag namespaces that are as different from plain short tokens as Bluesky's user-names are from typical single-site handles
permissioned tags, where some convention/rules can bless some users/posts to help audiences distinguish core users from spammers/interlopers – as when a conference tag doesn't want non-attendee/unrelated-spammer traffic
tags as macros to transclude entire prior-posts/memes/etc
2nd-party tags, eg: "my tag-mention is meant as recommended decoration of the post I'm replying to", as a cooperative, user-level route to the same sort of labelling that will also be occurring at other ATproto levels
etc
I sketched some vague ideas for 'strongtags' in a Bluesky thread a while back; the full possibility space & potential upside here is large, especially if back-compatibility with classic hashtags not a constraint.
As feedback for https://github.com/bluesky-social/proposals/tree/751dc2781dfe7680b63167e758fce28e1ab637ff/0003-hashtags, I'd suggest that to manage expectations and leave space for breakthrough innovation, Blueksy should take an explicitly two-pronged approach:
First, to meet the demand for hashtags-qua-'hashtags', match what people know from elsewhere, warts-and-all.
Just as on the web, where "users spend most of their time on other sites", Bluesky users will have learned most of what they know about hashtagging from other systems, and indeed even do most of their hashtagging on other systems.
So to the extent the behavior is called 'hashtags', & involves short slugs started with
#, perhaps with autocomplete suggestions, that then become reader-clickable links (either at compose time or later), less surprise for users is best.Classic hashtags will span across networks, just as they've invaded older non-hypertextual media like billboards & print ads. And, to the extent multinetwork clients & crossposting tools arrive for open systems, minimal classic hashtags have immense inertia as a familiar, lowest-common-denominator folksonomy & discovery tool. (Composing a post with classic hashtags once, posting to many varied systems, should still be kinda easy and useful.
So, don't hold up the boring-but-necessary work of providing the usual baseline while other more-bluesky/greenfield possibilities are discussed/designed. Just get working…
…then declare victory on 'hashtags' to focus on next-level stuff (per below).
Regarding autosuggest, running a central service brings offensive-token-policing complexity & costs - so a safer initial course would be to:
Then, autosuggest only shows things they could have seen (or even did see) elsewhere in their client. Curating their feeds is the same as curating their autosuggest, & (if all else fails) they can turn off unwanted term risks entirely.
Similarly, the safest initial contents of an "explore #tag" page would be occurrences of that tag from only the user's existing chosen feeds/viewable-posts – with options (perhaps sticky with user choice) to visit offsite searches/support-feeds/etc.
That then gives space for the other prong...
Second, pursue breakthrough better-than-hashtagging functionality, under some distinct new name, to avoid encumbering the new with old syntax- and expectations- interference.
In scope here would be new mechanisms/syntaxes/behaviors for:
I sketched some vague ideas for 'strongtags' in a Bluesky thread a while back; the full possibility space & potential upside here is large, especially if back-compatibility with classic hashtags not a constraint.