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?
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.