what is an interesting post? the greatest question in the history of autost, locked after 12239 commits of organic growth
autost was written in a month-long daze after cohost announced their shutdown. it started out as a way for me to archive my own chosts on shuppy.org. since the plan all along was for me to continue chosting from there, that came next. then it gained the ability to import posts from other blogs, archive the chosts of everyone you follow, and archive chosts liked by you and your friends.
buried deep within the core of autost is some gnarly logic that decides which posts should be rendered, which posts should be unlisted or publicly visible (“interesting” posts), and which tags should have their own tag pages (“interesting” tags).
the problems i wanted to solve initially were:
- i want to archive my own chosts and continue chosting on the same site
- i want to curate which of my archived chosts are publicly visible
- we need a way to store the posts that are being replied to
but the way i solved them was a bunch of hardcoded rules:
- posts you make with autost are publicly visible
- in practice, this means posts authored by your
[self_author] href
- in practice, this means posts authored by your
- your own archived chosts in “interesting” tags are public too
- in practice, this means posts authored by your
other_self_authors - it’s “your own” if you authored the last post in the thread
- the “last post” does not include transparent shares
- “interesting” tags are those linked in the top nav section
- in practice, this means posts authored by your
- specific archived chosts can be made public or unlisted
- posts in subdirectories are ignored except for rendering replies
there are so many problems with this model:
- you can’t put any posts in subdirectories
- you can’t opt out of the rules for archived chosts.
autost cohost-archivehacks around this by setting the[self_author] hrefof each archive to a cohost url - you can’t organise posts in any way other than tags.
autost cohost-archivehacks around this by making a separate site for each project you follow - there’s no clear way to know why a post exists, or what you want to do with it, other than this big pile of emergent behaviour
- since every site has to abide by the same rules, any changes to the rules could break existing sites or change how they behave
we need to move away from these hardcoded rules. i think it’s time to sit down and actually define what we want autost to be capable of, and design a data model around that. this will require changes to existing sites, but we can build automated migrations or migration tools to upgrade those sites.
when you render your site, we should ask questions like “do we render this post?”, “is this post publicly visible?”, and “which tags have tag pages?”, but let whoever created the post (autost server, autost cohost2autost, autost import, or you) decide the answers.
we’ll probably want to store those answers in a database. it’s all files right now, which is like a database, except harder to extend and harder to safely mix human changes and machine changes. having a database may make it easier to extend autost to do other things with archived chosts, like organise the chosts of everyone you follow into a single browsable archive, or generate a page of your liked chosts.
we may even want to move posts that only exist for rendering replies out of the posts directory and into a separate store, like the attachment store. this will require changes to the <link rel=references> in existing posts though, so it would need to be done with extra care.
