Ideas List

  1. Project: Twidere port for twister
    • Brief explanation: Twidere is a powerful and feature complete, free software (GPL), Twitter client for Android. Porting Twidere for twister involves replacing the lower level Twitter REST API of the internal twitter4j copy for the twisters’ own JSON RPC API. Preliminary work has been done implementing a functional JSON RPC client + authentication in Twidere but each microblogging operation (reading, posting, retransmitting etc) has yet to be ported. There is no direct 1×1 equivalence of Twitter and twister APIs so this is not just a simple URL remapping. The primary mechanism of user identification in Twitter REST API is a globally-assigned number which has to be replaced by the twister’s username string. In order to require minimum changes to all the Twidere’s internal functions, a possible solution may be setting a local table to map temporary IDs back to username strings.
    • Expected results: Provide a well designed and polished user interface for twister on mobile devices, with at least a minimum set of the microblogging features.
    • Knowledge Prerequisite: Java and Android development. Twidere is an easy-to-compile Android Studio project using Gradle.
    • Difficulty: Medium
    • Mentor: Miguel Freitas

  2. Project: Use twister-html as a basis for a new Chrome App
    • Brief explanation: twister’s main client is a HTML5 + Javascript based app which connects to a native daemon (twisterd) running on the same machine. In this usage model, the user’s private key is kept by the daemon that performs all the encryption tasks. In order to be able to support a different usage paradigm, one where the user doesn’t have to install a native client, work has been done on implementing all required cryptography in pure Javascript. Currently all authentication and crypto primitives have been implemented already. However, in order to securely distribute this new twister client, as user cannot simply trust any server for Javascript delivery (it may contain malicious code), an authenticated distribution mechanism such as Chrome Store has to be used. With signed twister app installed, then one would be able to choose any random server/gateway to connect into twister P2P network. This project involves not just packaging twister-html as a Chrome App but also replacing some plaintext operations with their Javascript-based crypto equivalents. Changes to UI are believed to be minimal.
    • Expected results: Chrome Store’s twister App which may allow people to use twister without installing a native executable.
    • Knowledge Prerequisite: HTML, Javascript.
    • Difficulty: Medium
    • Mentor: Miguel Freitas

  3. Project: Reduce battery usage of twisterd Android
    • Brief explanation: Although twister daemon has been successfully compiled for Android devices, a major impeding issue for widespread usage is battery drainage. Since twisterd keeps running all the time, maintaining several connections to the P2P network, mobile’s battery is rapidly depleted. One possible solution is adding code into twister-webview-app which detects when phone screen goes black and then put the daemon to sleep as documented in this open issue #2.
    • Expected results: Reduce power usage in Android port.
    • Knowledge Prerequisite: Easier project, limited Java and Android experience required.
    • Difficulty: Easy
    • Mentor: Miguel Freitas

  4. Project: Support of file attaching (and more)
    • Brief explanation: twister currently supports and distributes only limited size text posts. A proposal for adding support of file attaching has been discussed in twister-dev mailing list here. In short, the idea is that a new “media” torrent should be created per-user for his file attachments. Then some strict controlling may need to be set on others users to decide how they want to help sharing of their friends’ media (maximum file size etc). This is not a simple project as it requires ability to dive deeply into twister-core and libtorrent C++ code.
    • Expected results: New options to attach files and media to posts and UI to control torrent sharing limits.
    • Knowledge Prerequisite: Good P2P networks understanding, good C++ programming abilities, HTML and Javascript.
    • Difficulty: Hard
    • Mentor: Miguel Freitas, Denis Ryabov (?)

Suggestions? Questions? New ideas?
Join the twister-dev mailing list!

8 comments on “Ideas List
  1. @anomalyuk says:

    Subkeys.

    If more casual users are going to use the service over mobile apps or third-party websites, that puts keys at risk far more than using them in a daemon on a linux box. It would be safer if the risk were not so much all-or-nothing.

    My suggestion is that the authority of the user’s key can be delegated temporarily to another key, by posting something like a “new user transaction”. It would say something like “key abcdefg will use key hijklmn for posting messages only, up to 2015-06-12T00:00:00Z”. It would be signed with the user’s original key (which I think of as the “master key”).

    That user can then install the private key for hijklmn into a mobile app or third-party website. They will need to reauthorize (i.e. create a new key pair and post another delegation) by the time the previous one expires to go on using the app, but if the key is compromised, the attacker only gets temporary use of the account, and can’t wipe out the profile or do various other things. It slightly resembles GPG subkeys. There could be flags for the different capabilities a subkey could be given (post, change profile, add follower, remove follower, etc.). It would also be possible to revoke a subkey, again by posting a transaction signed by the master key.

    I was originally thinking these transactions would go on the blockchain, but there’s not really any need for that—they don’t need proof of time of issue, and they derive authority from the master key on the block chain. They could be attached to the user’s profile, or maybe even just treated as messages, either of which would be more scalable than adding anything to the blockchain that doesn’t strictly have to be there.

  2. Andrei says:

    Hi Miguel!
    Can you make it for Firefox OS Phones?!

  3. adeor says:

    I think it would be a good idea to upload the android client to fdroid (https://f-droid.org/). That would make upgrading much easier ….

  4. Daan Wynen says:

    Three cheers for f-droid!
    Regarding 1. and third-party integration in general, signed posts (i.e. sending complete raw transactions) could be pushed so that there would be no need for logging into anything (other than entering the key on one’s own phone).

  5. James says:

    How about making twister a wifi-distributed phone app?

    At music festivals, everybody bashes at their phones, looking for their friends, yet unable to reach them on account of no reception.

    If twister became an app that people could take to large gatherings, each gathering could have its own blockchain, and we wouldn’t rely on any phone provider for reception.

    This is a problem that needs solving in Australia, and I know people who work in festivals that would be happy to work with such an app.

    Plus, this is an instant incentive for people to start using blockchain related apps. It solves a very real problem.

  6. Geremia says:

    Re: “Project: Use twister-html as a basis for a new Chrome App”:

    Instead of porting the native client entirely into JavaScript, why not use WebRTC to handle all the P2P connectivity? See, e.g., WebTorrent (source) or WebRTC-explorer source (WebRTC+DHT).

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>