Glossary

Hashtags is a concept of social tagging of messages, not to be confused with technical tagging of messages, typically in a client-server communication.

Hashtags in particular come from Twitter and define a way to submit a message over several distribution contexts additionally to the default context, which in the case of microblogging is the list of personal subscribers.

Implementation

PSYC could support the hashtag user interface additionally to our traditional slashcommand approach. The question is, how should we map it into PSYCthink? And if so, would the person entity be in charge of parsing the message in order to detect such tags, or should it be the client's job, or whatever the user's agent is? Also, would it be applied to presence announcements only, or does it happen with each and every line of chat?

The microblogging approach would be to have the hashtags map to some central directory of contexts, thus enforcing a central namespace of tags. There can only be one #linux, for instance.

Another way to deal with it could be to map the tags to a local server's places, or run a per-server directory of tags pointing to potentially remote contexts.

A more psycish choice would probably be to detect hashtags and map them to channels, since channels share the same # character prefix. This also means each user would have her own namespace of tags. A client parsing the tags would then ask the user what she intends by a tag as yet undefined.

When thinking in terms of channels as they are currently defined, the tags would always represent a subchoice of her existing subscribers. Should we allow channels to be aliases pointing to remote contexts? Then she would be prompted to suggest a place where to submit this message to. But should she submit things to contexts she hasn't actually subscribed to (as is commonplace in microblogging)?

Yet another approach would be to have a per user nickspace of contexts containing both her own channels and all the places and people she subscribed. The @person microblogging syntax may be more natural for this scenario.

We could actually support two of these flavours, #tag and @recipient, with just slight semantic differences, as they are technically very similar.

Distributed Hashtags

A very frequent request by the FSW and microblogging community is to be able to collect and view all updates that contain a certain hashtag on a single page or as a continous feed.

In a decentralized & federated scenario this spells horror as you either run a collecting agent which connects as many as possible federation servers and subscribes to certain hashtags, or you define some centralized architecture (like resolving <hashtag>.hashtag.int by DNS), then expect all social tools to deliver their updates to that single node where others can pick it up, likely to create a single point of failure (at least a different one for each hashtag).

What if a distributed hashtable was used instead? In a DHT of more or less trustworthy nodes, consuming agents can register certain hashtags redundantly (like three agents subscribing to #summer). Producing entities look up the respective hashtag, then walk through the list of consumers and send them the new update. If the DHT actually points to a multicast distribution tree, even better. This would allow to implement a Twitter wall for a decentralized or distributed network of update producers.

One possible form of DoS attack in this scenario would be to register many invalid consumers and create excessive load for the producers at delivering time. This can be addressed both by the DHT at registering time and later by the producer, trying to weed out bogus consumers. A trust relationship between involved partners would be helpful. Also the SPAM-negating effects of a multicast tree not only improve distribution but also reliability.