I made an open source mastodon web client with a user-controlled algorithmic feed and threaded posts. It's not done yet, and has some rough edges, but it's to the point where I'm using it as my main feed reader. jefftk.com/p/introducing-shrub

Follow

@jefftk I have considered making something similar to this myself, but I am not clear what the best level is to inject my own "feed agent". The downside of a custom client means that you cannot take advantage of existing feature-rich clients — even if you fork an existing web client, you'd need to maintain a separate mobile app if you use different mobile and web clients (as I do).

@jefftk Another way to accomplish this would be with a custom fediverse server (e.g. make your own instance). Any existing clients would be able to use it just fine, but then you have to run your own instance and you can't join an existing instance.

It would be nice if Mastodon had a system for user-supplied plugins, but allowing users of an instance to execute arbitrary server-side code requires a high trust relationship, unfortunately.

In the end, custom clients might be most practical.

@zebrask "arbitrary server-side code requires a high trust relationship"

Not necessarily: you could use a language that is easy to sandbox, like Lua or WASM. The hard part is figuring out what inputs and outputs the plugins should have access to.

@jefftk I don't think it's impossible but this is definitely a hard problem. If you want to enable people to do stuff like use ML recommendation systems, you either need to give them plenty of compute (which they can then use to mine bitcoin) or give them a way to make requests (which can be abused in a number of ways).

People *do* run services that allow arbitrary server-side code execution, but my impression is they have to be kinda carefully designed.

@zebrask "you'd need to maintain a separate mobile app if you use different mobile and web clients"

If you have this level of control over the client you could make a web interface that you liked on both mobile and desktop. Mostly the same, with a few @media queries for the important differences.

@jefftk Well, my point is that for mobile I actually like the existing native clients better than existing web clients. Right now my choice of client on the two devices is uncorrelated. If I have to fork a client to add my own capabilities, I need to choose a compromise client that is acceptable in both form factors or fork two clients.

Neither is insurmountable, but it's not ideal.

Sign in to participate in the conversation
Mastodon

a Schelling point for those who seek one