What needs to be done for an initial release?

JortJams is shaping up well, but it has some major missing parts that must be filled in before a first release. This page is based on the initial release milestone from JortJams’ Gitlab project.

There is a separate page describing missing features that, while they may not make the initial release, are still on the short list.

Follow accounts

JortJams currently supports fetching statuses by hashtag. However, it is also very useful to pull statuses from accounts (or at least those statuses that don’t require authentication to view). The goal is to be able to pull statuses from any ActivityPub actor, using either a WebFinger identity (@someone@example.com) or the actor URL (typically the profile URL). This is the goal of issue 106.

Account muting/blocking tools

There are many reasons to mute or block an account from showing up in JortJams. Here are a few scenarios:

  1. The account is a bot that posts every song that someone plays. You like to sample songs posted by this account, but the account dominates your JortJams views because of its frequent post rate (and because a lot of those posts are repeats). You would like JortJams to deprioritize bot accounts. This is the goal of issue 129.
  2. The account is posting a lot of things you don’t care about right now. You would like JortJams to ignore everything from that account for a few hours or days.
  3. The account posts music or audio you don’t want to hear. You want JortJams to remove all audio mentioned by that account and to not display anything from that account in future.
  4. You don’t like the person associated with an account. You want JortJams to remove all audio mentioned by that account and to not display anything from that account in future.
  5. You only trust a certain set of accounts. You want JortJams to not display anything from accounts that aren’t in the trusted set. This is the goal of issue 148.

Security by compartmentalization

The network and media decoding code in JortJams has too many privileges. Specifically, code that handles data off the network or decodes media has read/write access to the JortJams database. It is theoretically possible for a hostile entity to craft a media file or text status that, when parsed, causes code execution that corrupts or discloses contents of the JortJams database.

(The mechanism by which such an attack would be done is not known, but the mechanism isn’t the point. The point is that the network code has the capability to directly access the database, but it should not have that capability.)

There are two major changes to make:

  1. The JortJams fetcher program needs to be launched in such a way that it has no knowledge of the database: it must communicate on standard channels only. The parts of the fetcher program that read or write to the database must be run through a broker process; that broker, of course, will not be able to access the network. This is the goal of issue 153.

  2. The JortJams media pipeline currently runs with the same capabilities as the fetcher and GUI. However, that code does not need access to the database. It should be possible to start a media decoding pipeline with the necessary restrictions. The ipcpipeline GStreamer element might provide a start at this.

Finally, the GUI also performs some network operations: avatar image fetch, host feature detection, and media identification. These should also be run in a restricted environment.