@hipsterelectron @aud @ireneista @impactology for example, i still haven't had time to get a MWE together even if all the pieces are in place, but it's simply not true that activitypub can't do custom feeds. the protocol explicitly gives a key streams as "a list of supplementary Collections which may be of interest," and it is trivially implemented in mastodon by modifying the list system to allow lists to contain a list of posts, rather than a list of accounts. one could go further by allowing people to make those feeds public and followable, again both implicitly via mastohacking or explicitly with the protocol since they are Collections like any other.

That would mean that you could have algorithmic feeds computed by a single skiddie with a python script on their laptop that gets run when they feel like it all the way through the same kind of big-world feeds bluesky imagines. your instance is the thing that shoulders all the expensive parts of serving the feed and federation as fedi works now, rather than the atproto model where to have a feed means you need to run a pretty beefy, always-on server. I was working on a json-able DAG system of features and transformations so that if someone had a feed design that they liked, you could just copy it, tweak it, make it your own, and so on - and eventually exposing that via mastodon itself so that you don't even need the additional other computer, your instance handles the whole thing for you.

So algorithmic feeds are things made by people that respect current norms about post access by going through instances with your account as the agent and hosted by the instances we (hopefully) help sustain either with donations or time, rather than products that we are lucky enough to rent.

#ATProto #DIYAlgorithms

GitHub - glitch-soc/mastodon: A glitchy but lovable microblogging server

A glitchy but lovable microblogging server. Contribute to glitch-soc/mastodon development by creating an account on GitHub.

GitHub
one weird trick to implement #DIYAlgorithms: make the masto lists API endpoint accept an array of Post IDs. boom, then you can implement whatever the fuck algorithm you want, wherever you want, and all the server needs to do is show those posts. wishing a kindly felt "eat my ass" to atprotocol https://github.com/glitch-soc/mastodon/compare/main...sneakers-the-rat:mastodon:feature/postlists
GitHub - glitch-soc/mastodon: A glitchy but lovable microblogging server

A glitchy but lovable microblogging server. Contribute to glitch-soc/mastodon development by creating an account on GitHub.

GitHub
Alright i am working on #DIYAlgorithms again after a long hiatus for other stuff, and i have finally been coerced into learning Python's asyncio instead of just using threads and multiprocessing. If what ppl need to think the fedi is cool is feed algos, we are gonna have the most transparent, most runnable on a raspi, least server-intensive, least surveillance capitalist algos on the web.
pinafore-mahoot/README.md at master · mitotic/pinafore-mahoot

Curating web client for Mastodon. Contribute to mitotic/pinafore-mahoot development by creating an account on GitHub.

GitHub

@lili
I agree, but I also think there's a balance to be struck with opinionated design, with masto itself being a decent case study. like inevitably someone will want to make a feed that sorts people they interact with more frequently higher on their feed, which seems very normal to me.

so what might other ways of making that healthier look like? one way might be to add some explicit noise, weighting, or damping parameter that prevents that from being the most dominant feature. if that parameter is under their control, they can decrease it until it isn't a harmful feedback loop. to help with that, another idea might be to offer a toggle switch to generate an "inverse feed" across the whole algorithm or a single parameter on it - what is getting filtered out of my feed as a result of how it's designed? that would make it easier to identify things that might be driving them into some unhelpful bubble or etc.

just thoughts, I think the whole question is v far from simple so thinking about what a healthy social internet looks like is never final or complete for me

(forgive me for tagging and making public, this is largely a way of taking notes to self through another imperfect UI lol #DIYAlgorithms )

Ok I'm gonna try and do 1 hour on #DIYAlgorithms per programming day until I get a reasonable prototype with some basic Algo examples, that'll be here: https://git.jon-e.net/jonny/diyalgo
prior context here: https://wiki.jon-e.net/Masto_Forks/DIY_Algorithms

the first things I think are simple but the most requested ones I've seen on here:

  • #NRecent : feed with just the most recent n posts from everyone - to balance us adhd hyperposters with ppl more careful with their words.
  • #ChronoMatching - to rotate your friends who post at different times from you due to time zone/sleep cycle/etc. into your posting cycle.
  • #ExclusiveFeeds (@lina ) - a copy of your home feed without posts that have been included in an exclusive feed (and the exclusive feed itself) for situations like eg. #monsterdon where you don't want to mute something but you don't want it to flood your feed

for now this all just works by POSTing an array of status IDs to a modified lists endpoint in order to be maximally general/interoperable with other Algo implementations. things like NRecent make me think there should be some way to do diffs instead, where you remove one item on the feed and/or insert one in a position too tho. maybe I am preoptimizing.

I am thinking the way to do this will be to have a system of
a) features that can be lazily computed for different object types (status, account, or derived types like lists of accounts, etc.)
b) a tree of procession steps with each node returning a value bounded 0-1 and the root being used as the position on the feed. posts that should not be put on a feed have a special value of NA that terminates processing the rest of the tree.
so that
c) an algo can be defined as an easily serializable eg. JSON/ #JSONLD-like format that specifies features as dependencies and then describes the processing tree with an array of node objects, each pointing to some node type (and where it comes from, to plan ahead for plugins), parameters, and how it's connected in the tree.
d) eventually, new URL routes/API endpoints so you can link to, follow, and re-use other people's (opt-in public) algos in-medium.

the goal is to get very low-fi, ie. no big data, inaccessible hardware requiring NLP or neural nets and shit - explainability and transparency by designing simpler qualities that people combine in specific ways. yno. like .... designing an algorithm on purpose. for our own benefit, not some investor.

#LongPost #MastoDev #MastoHacks

diyalgo

DIY Algoritms for mastodon

jonny's computer website
@futurebird
i gotta get back on this. I bet I could put this together by this evening. how about instead of having it be an option for your home feed, it's one of many different feeds you can select between? or would you rather it be an option for every feed?
#DIYAlgorithms
GitHub - hodgesmr/mastodon_digest: A Python script that aggregates recent popular posts from your Mastodon timeline

A Python script that aggregates recent popular posts from your Mastodon timeline - hodgesmr/mastodon_digest

GitHub

it seems like a simple #DIYAlgorithms would be a #TimeWarp algo: the posting time for people you mutually interact with more decays more slowly, or is stickier at the top of your feed.

maybe tunable with two single exponential functions for
- strength of time warping and
- duration of past interactions to compute time warping from
or whatevs