$half-shot.uk 'Stuck in the past' edition

Bark: Microblogging in Matrix

By Will "Half-Shot" Hunt

Matrix seems like the ideal framework on which to build a microblogging system. In essence, a microblog is just a selective messaging application where you choose who you subscribe to. I plan to create a full implementation of a microblog (using examples such as Twitter and Google Plus as an influence on it's look) on top of Matrix. This involves building a structure to accommodate features such as ‘replying’, 'following' and a ‘central timeline' inside a client, to make it usable for everyone.

I have a huge interest in building a distributed service similar to existing microblogs, and 'Bark' is basically the opportunity I have to prove that one is viable, while also proving that Matrix is so much more than just a group messaging system to the masses.

Why Microblog in Matrix

Design

Rooms

Rooms will act as a user’s stream. Every user that joins Bark will create a single room on their homeserver which would serve as their personal ‘timeline’. They can post to it and allow/deny other users access to it. This gives the stream owner some flexibility about allowing people to read their posts and if they want people to 'write on' their stream.

A user may set their biography (a small piece of text about themselves) as their room topic. Following a user would be as simple as joining their room. Replying to a user’s post would be as simple as sending two messages. The first would be '>replying to:eventid' where the eventid is the previous message. Secondly, sending the reply body.

This should allow for other clients to understand what is being said even if they don't understand the microblog format.

Room naming is more tricky due to the variety of permissions that users may be allowed. The Bark client will create a room for the user on their homeserver (this would be a requirement) upon login to the client if it does not exist. The rooms name would be 'Bark - DisplayName' which would be searched for upon each login. You can set whatever permissions you want for this room to make it discoverable or not.

People who wish to add you may do so by either typing in your rooms alias if it has one, or your internal ID if not. The idea behind using this system is that we can provide the users a way to keep total control of their content via the rooms permissions control.

Client

The client would be a single page webpage, which simplifys the process explained above. In addition to setting up the users room once matrix details have been given, it will listen for messages on each Bark room. It will then sort them into a single stream. The messages would be interactive (e.g. you can 'reblog' them). The client would also have the media features implemented like taking a picture or sharing a audio/video file.

Searching for users would be limited at first to your own homeserver since matrix doesn't have a global index system, but you can add people by internalID or alias (the latter being automatic if it exists). Bark rooms would have an included state event to ensure that the room is 'Bark' compatible. One way we could work around the issue of searching could be a global 'phonebook' approach. A room on matrix.org would be dedicated to listing clients by display name and sender id which would be optional. Users could search this room to find people to subscribe to.

I would also implement a few new event types which would not be well represented by the 'm.room.message' type.

'org.bark.repost'

It's currently not easy to quote a person in another room, which is essentially what reposting is. The event would have a field for the quoted event id and the stream that sent it so the client could find the post and get information about it's body, likes and other stats if available.

'org.bark.like'

Essentially, this would be posted whenever you click like on a persons post. It would be send to the stream and then other clients can count each like for a post by the linked event id inside.

'org.bark.user'

This would list a user's (current at the time) display name, sender id and (current) biography. These would be posted to dedicated 'phonebook' rooms which would allow people to do simple searches for users.

Sketch of Web App

Deliverables

Timeframe

Week May June July August
1 /////////////
2 ///////////// M.⚀ (Fri 12th) M.⚁ (Fri 8th) M.⚂ (Fri 12th)
3 ///////////// Final Submit
4 Begin:28th ///////////////

Milestones

⚀ Milestone 1 : Basic Functionality

My first milestone for the project would be to deliver on the basic aims of the project. The CSS would be minimal right now as at this stage I will be focusing on good code quality first.

⚁ Milestone 2: User Interface

Milestone 2's objective is to have it ready for testing by anyone.

In addition, I plan to give this to users to test and get some feedback.

⚂ Milestone 3: Extra Features and Testing

This milestone will be mainly checking that everything is in place and the usability is there.

Extra features to implement at a later date

Why me?

I’m currently a 1st year student of Computer Science at the University of Portsmouth in the UK.