Roadmap

Refrain is, currently, very bare-bones. Its initial version focused almost entirely on the basic design of the service and proving it out. There are a lot of features that would be very nice to have and, in the fullness of time, hopefully it will get them. Below is a short list of the features planned and some very rough, back-of-the-napkin thoughts about implementing them:

  • Chat Search
    • will implement this with Postgres fulltext search
    • need to be careful about performance here though, FTS can be expensive
    • also need to give some thought to how to structure the results
      • messages are ordered by time, and you need to show some context on a match for it to be useful
      • a single message in isolation is hard to parse, and the way discord does this is kinda wonky
      • debatable if theirs is the best style
  • Server metrics
    • it would be very nice to be able to see how much traffic is going through the server and through which channels
    • we already keep an in-memory counter of the traffic each connection uses for each type of session
    • wouldn't be too hard to keep it running and report it to an aggregator downstream with rabbitmq
      • could emit captures of total session time and total bytes sent/received for each connection to a stream every 5-10 seconds
      • a consumer could read the stream every minute or two and update a table of stats
  • Blocking users
    • Need to be able to block users from sending you direct messages
    • requires a new "blocklist" model object tied to the user
    • should be able to block by username or home server
  • Chat tagging
    • include the ability to @ someone and add them to a list of tagged users in the delivered message
      • should allow @ to target roles as well
    • this is actually a deep one, as it implies notification filtering to really be useful
      • need to be able to say, "only send me a notification when I'm mentioned"
    • notifications are client-based today, and still could be with this
      • would need to store the notification settings persistently server-side
      • could have the client apply filtering logic to received messages based on those settings
    • the persistent notifications are trickier, as those are based on simple offsets today
      • the API to track read cursor just counts the number of messages between the latest and the cursor
      • could have it apply the filter to each message it processes?
  • End-to-end encryption for DMs
    • technically, client-side storage is the only way to be perfectly secure with E2EE. the server has literally zero knowledge of the key.
    • this is not really practical for the vast majority of users. it means that you have to always use the same device to access your account, and that doesn't work all that well.
    • Refrain would require a secure way to store the client keys in the server for E2EE to be usable for more than infosec wonks
      • this sounds weird, but the keys could be stored encrypted in a server-side vault with a password only the user knows and never shares with the server
      • the user's client is in charge of downloading the vault content, opening it locally, and generating the key material necessary for the server to encrypt
    • each time a DM is sent, the sender generates a key and distributes it
      • this is basically X3DH + Double Ratchet, AKA what Signal does
        • there is a time limit on message receipt with this model, but as long as E2EE isn't 100% mandatory for all DMs that's probably fine
    • don't think this is really practical for channels
      • key distribution would be...awful, even before federation
      • frankly, not sure that there's any meaningful need for this; communities are by nature pretty human and leaky.
      • maybe a special channel capability for E2EE?
    • federation makes this quite odd
      • Keeping a vault for federated users is scary. The password would, ideally, be the same to prevent the user from having to know a separate passphrase for each federated server, which means the vault contents are going to be identical and stored in less-trustworthy systems. Not good.
      • I think it's possible to keep the vault on just the home server and generate key material on federated servers ad-hoc
        • X3DH just needs the prekeys generated from the identity key, so generating more of them to send to federated servers seems reasonable
        • Does mean the client needs to manage key rotations on federated servers, but as long as the generation of them comes from the singular vault on the home server, this seems easy enough to automate
  • Community profiles
    • really handy once federation comes into the picture since usernames are only locally-unique
    • requires some new data to be stored/related to the community member entry
      • should mirror the UserProfile model
    • when present, the community profile should be used in place of the user profile in any community UI
      • member list
      • chat
      • channel rosters
      • probably more
    • requires a new community member settings UI
      • should probably refactor the community settings button to be part of a dropdown on the server name
      • member settings always show
      • if the user has access to change settings, an entry in the dropdown shows
  • Server theming/Community CSS definition
    • kinda like old-school reddit
    • allow community organizers to style their community when it's loaded (within reason)
    • catppuccin already supports basic theming through CSS vars
      • could maybe start with that? each server could control the basic color themes in configs
    • communities need more guardrails. the UI main stage + channel list should be the only thing that should be intentionally changed by a community's CSS
      • need to add new CSS vars, ideally these are the only things the community admins get to change
      • CSS vars are cheap to swap at runtime
  • Screenshare audio capture
    • This is doable in the native app with some work, browser-based screenshares are gonna be jank until standards improve
    • as of today, basically no browser does audio capture while screensharing well unless the thing being shared is a browser tab
  • Screenshare stream preview thumbnails
    • would require refrain-video to periodically snag a VP9 keyframe and convert it to JPEG on server
    • could store snapshot directly on the video session in postgres
  • Mobile clients
    • this is 100% necessary before Refrain can be truly useful to most folks, but it's a massive timesink
    • most likely just target Android at first since Apple requires a lot of hullabaloo
    • ideally, we could use Tauri to generate a mobile-friendly app that just loads the webui
      • the biggest gap for this today is the lack of WebTransport support, although there is a random plugin that purports to provide it
    • there are also some practical issues with the way the subscription client in webui works today
      • the browser will pause all active processing whenever it loses focus, which means the subscription client will stop responding to heartbeats
      • moreover, it won't process data from events when this happens, so the client will silently miss events
      • need a better, more graceful recovery from loss of signal like this