I’d like to share some thoughts on stuff i’d like to implement or improve in twister…
Following the recent introduction of “getmentions” api in twister-core 0.9.27, i’d like to explore the possibilities for creating new user following “types”.
Currently we have only two following types: public and private.
1) Public: the username is stored in public DHT and twister-core starts a torrent to follow this user. Public following are synchronized between computers (twister-html read back the listing from DHT)
2) Private: twister-core starts the torrent, but username is not announced to DHT. Therefore the posts appear in timeline but people don’t know you are following him.
The interface for “Private” is actually awkward / poorly designed: there is no option to follow privately from the start, one has to public follow (propagates the name to DHT) and then change it to private (removes the name from DHT). So for a brief time window one will know about that.
So one obvious improvement here is to change the interface. Perhaps opening a box to inquire the following type would be the least layout disrupting, also allowing for more types:
3) DM/Mentions only: this is a kind of “mute”, that is, the user might be too lousy so you want to follow him form mentions and DMs but not to polute your timeline. This is actually orthogonal to public/private setting.
4) Restrict charset: i’m not sure this should be a per-user setting or global one. The idea is to limit showing only latin, or russian or chinese posts.
Any other suggestions for following or per-user settings?
The above ideas only require HTML/Javascript coding. If someone wants to help it will more than welcomed 
Then there is something i’d like to explore in twister-core: bandwidth limiting.
I’ve being noticing that sometimes twisterd saturates my upload link and it seems to be due to high DHT traffic. I still need to investigate if this is caused by some bug in other twisterd nodes (requesting too much) or if someone is aggressivelly crawling the network.
Either way, i was thinking about creating a new setting to limit the amount of bw that twisterd may use to serve the other nodes. This also improves / works as DDoS protection.
My idea is that DHT requests originated on your own host would always be allowed to go out, while replies to other nodes would be subject to bandwidth accounting.
Comments?
I’d like the possibility to filter on the language, not only on the charset.
An automatic detection (with something like libexttextcat) would be inefficient for short texts, but may be we could add a field to define the language?
4 is very nice. There’s not much interest in following languages you can’t read. On the other hand it would be interesting to have a way to allow people you follow to bypass that filter somehow. E.g., you might want to receive messages in a language you do not understand from a specific person because then you can make the effort to use some translation tool, but generally want to avoid that language to pollute your timeline. So maybe filter on your timeline, but not when you visit someone’s timeline would be a good compromise without too much hassle.
3 is sane. I would call it “quiet” or “focus” mode instead of mute. Actually that inspires me another functionality for “mute”: keyword override. One could maintain a list of keywords, hashtags, etc., besides their own name, that would override mute mode. For example, someone could share very interesting view about #food, but otherwise be quite annoying with all kind of chatter. So when they mention #food, you can read them.
In general I would be wary of implementing limiting following types too early. 4 makes a lot of sense because it’s practical. But otherwise, the community on Twister still is small and activity very restricted. Maybe a public timeline by language could be interesting to have. If users mention their language of choice, there must be a way to follow that.
Thank you!
yes, that’s something we must also implement: a “dismiss” (x) button along the top trends. imho the list of dismissed hashtags could also be made public in dht, so your friends may configure their clients to ignore those tags as well.
Maybe it is possible to store the usernames of people you are following privately in DHT, but encrypted with your own key? Then it should be possible to sync them between clients.
The drawback would be, that other people can find out how many users you are following privately, but I don’t think that’s a very sensitive information.
If that is optional, and you store the whole list into a single padded file, you would leak much less information.
I have been thinking about twister’s blockchain and advertising for a while now.
The advertising approach really hinges on the viability the advertising platform (critical mass and all that).
It requires the clients to actually display the ads (a conflict of interest between individual and collective needs) and it also requires the advertisers to trust that the ads will be displayed.
Perhaps even more importantly, it puts the security of the whole blockchain into the hands of very possibly only a few mining advertisers.
Given that all we need from the blockchain is the identity management with the rest of the code being DHT+torrent it seems to me that using the ethereum blockchain would be a great fit.
It would eliminate the need for ads and give the twister usernames the security of a potentially much stronger blockchain.
Now, I am only beginning to grasp the concepts behind ethereum, so maybe I am missing crucial parts here and I would be greatful if someone pointed that out!
For example, I don’t quite get who would pay the “ether” to run the identity management and if that would even need to be a core part of twister or a related but distinct ethereum Ðapp.
But it seems like a good fit for me…
no objections, go ahead. heh, https://github.com/miguelfreitas/twister-html/pull/209
cool! while we’re on it i think we should at least prepare the layout for the other options as well (at least the “mute”/”quiet” thing)
all other methods or types of following besides public-private are not about visibility_of_following_for_other_peers but about type_of_filtering_posts_for_user. so I suppose we should separate them signally in distinct section of following configuration UI.
i kind of agree… but, if we create this new “properties” modal it can be reused on both cases. i mean the same modal can be shown when one clicks “follow this user” and “edit properties for this user”.
Like:
—
(o) public / ( ) private
[x] show posts on timeline
[OK] [CANCEL]
—
this is just my feeling, not a hard objection. i like leaving the final decision to whoever is coding
indeed. it was one of my expectations when I worked on last commit. I like the way you dance.