astr-hal

thank you cohost

  • he/him but anything works honestly

21 🇵🇭 🇹🇼 bi tme transmasc
i like drawing ocs

18+


carrd (has twitter & instagram)
astr-hal.carrd.co/
neocities (work in progress)
astr-hal.neocities.org/

bluetinge
@bluetinge

Can we recreate Cohost in a decentralized environment?

It's been great to see so many people planning to keep the Cohost community alive by sharing links to their own blogs following one another through RSS. In theory, something like Cohost should be entirely possible to recreate through decentralized networks — even as we move to different blogging platforms or create our own websites, we can use RSS to follow one another and stay in touch. The barrier of entry is incredibly low: platforms like WordPress and Tumblr already offer RSS feeds, and tools like the excellent RuSSHDown even let you create an RSS feed all on their own!

But there's still something missing... Or, well, there's plenty missing, but one thing in particular stuck out to me: reblogging. Sharing and reblogging content is a huge part of any Cohost-like system... is it possible to recreate it without relying on a centralized server?

Gif of scrolling and hitting reblog button

Note: the default styling is a bit basic but it's all easily customizable!

The above is a reblog button that I've created that's intended to work on as many different systems and platforms as possible. I have a widget for creating one on the main page at rssr.bluetinge.dev, which doubles as a tool to reblog any RSS feed on the internet, and a sample page of what the results could look like here, but if you don't mind, I'd like to explain a bit about how it works first and make a case for why people should give it a try! And if you
don't have an RSS feed or blog yet, scroll to the bottom where I have a tutorial on how to get started! 


Okay, so, what is this thing?

RSS-Reblog— as I'm currently calling it, though admittedly it would be nice to have a catchier name — is basically just a link that you can embed at the bottom of your posts to let people reblog it (whether to another platform or your personal website of choice). You use rssr.bluetinge.dev to generate the link/button for your posts, or even to reblog other people's posts who don't have the link. (It keeps the original author data and links back to their original post and feed).

When you reblog a post — whether that's from the above webpage or by clicking on the reblog button — it brings you to the webpage below where you provide your own RSS feed, adjust how your display name and icon are presented, and (optionally) add your own text (in HTML or markdown), adjust tags (the reblog tag is provided automatically), and/or provide a link you want associated with the post:

Gif of generating the reblog

Once you hit generate, you're able to view a preview of the post. As we can see here, it's added a couple headers around the original post (replacing any pre-existing headers it's able to find), and same with a footer with a new Reblog button. Here, you have some options for what to do next depending on your personal preference.

  1. If you maintain your blog purely through your RSS feed — maybe you use RuSSHDown to make new posts, and use RSS2HTML to generate your blog webpage (if you even decide to have one!), then all you need to do next is download the new rss.xml with the new post item added to it. If you want to double-check the results or make any edits, you can take a look at the generated RSS file instead, and copy it to the clipboard when you're done. And if you're reblogging several posts at once, you can always save the file to local storage to reuse, so that you only need to download it once at the end (this feature should be live in a couple hours — I'll edit this post when it is).

  2. Already have your own blog site? No problem! For example, maybe you have a Neocities site where you have a blog you've worked super hard on to get custom styling you like. All you need to do is copy the newly generated HTML or markdown and put it as a new post in your blog, making any edits you'd like to make first. If you don't autogenerate your RSS feed, you should download the rss.xml as well, since the reblog button doesn't work unless it can find the post to be reblogged on your feed. You can always host this file as a separate rss feed specifically for reblogging posts, if you're nervous about overwriting the old one with something autogenerated or just want to keep things separate. If you do autogenerate your feed, well, see #3 below.

  3. Host your blog on WordPress, Tumblr, etc. and use that to generate your RSS feed? That's totally fine! In this case, you can just copy the markdown or HTML to make a new post, same as you would make any other post, and presto! There is one caveat — the reblog button at the bottom of your new post only works if you either A. Provide a link to your reblog of the new post now, which might not always be possible if the new link is autogenerated, or B. Download and host this rss.xml separately from your main one. In other words, you'll keep using your main, autogenerated RSS feed for everything else — it's the canonical feed that you give people to follow you, etc. — but for the reblog button specifically, it will find your posts from this separate feed in order to make sure the reblog button always works. (Hosting it is free and super simple — see how-to-get-started below).

I'll add that if you don't like the default style of what's been generated — the button, the colors, the fonts, whatever — the generated HTML has CSS classes you can use to format it to your heart's content! Keep in mind that feed readers will strip a lot of custom styling, so the generated code includes some basic inline styles to fall back on. See a guide to using the CSS hooks here.

Cool, but is it secure? Private? Does it have bugs that'll mess up my feed? Let me see the source!

(Snipped — Moved to my blog to make this post a more manageable size!)

Okay, but, how do I know when someone reblogs my post? And what about likes? Comments? Notes?

Yes, that's absolutely important! On a blogging site like Cohost, you receive notifications when someone reblogs your post. That's totally doable using a decentralized distributed network, and so are likes, comments, tumblr-style notes, etc. I'd argue it's actually very important for forming a community — you want to know when people reblog your posts, you want to interact with others through comments, you want to like others' posts without reblogging, you want to discover new people through tags... Unfortunately, this is all beyond the scope of where I'm at right now. I would really love to implement all of this, though, and I do have some ideas. Feel free to follow me at bluetinge.dev/rss.xml to get updated when I update this project, and you can always feel free to contact me on Discord if you'd like to chat or collaborate directly (I'm @BlueTinge).

Here's a shortlist of planned updates and what I'd like to do: (Snipped — moved to my blog to make this post a more normal size)

That's great but how do I do get started please tell me already

Yeah, okay! Here's a simple guide to getting started with RSS (using GitHub). If you already have your own blog (tumblr, your own site, whatever) and want to keep using that, you totally can: just follow the below steps to make an RSS feed that you can use to reblog other people's posts.

  1. Make a new RSS feed: You can use RuSSHDown for this! It's pretty self-explanatory: the only special note I'll make is, if you don't have a website yet, just put down "Link" or something for the website link and we'll edit it later.
  2. Host the feed: Make an account and new repository on GitHub. Once you've created the new repository, upload your rss.xml file to it get the "raw" link to the file. You can find this by clicking on the file, and clicking on the "raw" button in the upper-righthand corner (its behind the three-dots button on mobile). As an example, the link might look something like this: https://raw.githubusercontent.com/bluetinge/bluetinge.dev/refs/heads/main/rss.xml.
  3. Edit your rss.xml to have the correct link: Find the line that looks like this: <atom:link href="Link/rss.xml" rel="self" type="application/rss+xml"/> and change Link/rss.xml to the link you copied. If you are not planning to host a website, you can replace Link/rss.xml in the <link> tag with the raw github link as well — and you are done! Just use that raw link as the link to your feed (or, you know, make a bit.ly pointing to it or something).
  4. Host your site via github pages (optional): You can use rss2html to easily turn your RSS feed into an actual blog webpage — just follow the directions on the rss2html website, and embed it in an html page! I have an example of what this html page could look like here. I'm planning to update the style on this to make it look more like cohost, but hey, make it look like whatever you want!

And that's it! Please let me know if you think it's neat, or you have any questions comments or concerns! And again if you want to keep up with updates you can find me at bluetinge.dev/blog, or follow me at bluetinge.dev/rss. Thanks for reading!!


Reblog via RSS


@astr-hal shared with:

You must log in to comment.

in reply to @bluetinge's post:

That's a cute idea!
I could perhaps stylize it as ReSShaRe, so that it works with the existing RSSR namespace I've registered (for RSS-Reblog); or alternatively, perhaps it's early enough in the project that changing the namespace wouldn't be too bad... Hmm
Whatever I go with it's a cute name, ty!

it is neat! thank you! we still are not sure whether reshares are a good thing or a bad thing.

one of the most interesting dynamics about cohost is that, because there's no technical mechanism that keeps us from overwhelming people's feeds, we had to learn to be parsimonious with the resharing... there are still definitely times when we have reshared stuff, just, we had to learn to actively reflect on it.

compare and contrast other social media sites, which are intentionally designed to make that an impulsive decision.

we wonder what will wind up happening with rss reshares, long-term.

Thanks for the comment!

I think it's possible that with something like what I have now, the barrier of inconvenience for sharing (necessitating the upload a whole new feed manually) will have a similar effect of restricting how much users will share things, esp. since the worry about overwhelming others' feeds is still a real concern. I could absolutely still see that being misused, though.

I am now thinking a bit more about possible negative side effects of reshares, though. Were there other concerns about reshares that y'all had? I'm wondering if there are things I could do to mitigate potential negative aspects of this.

yeah - we weren't up for a long explanation last night but we had the same thought, that the fact your thing requires so much manual work will mean it doesn't lead to people being impulsive. we think it's a good direction for experiment.

it's also the case that the worst abuse-cases of RSS are not things we have to guess at, they're things like attempting to steal a feed (and put ads on it...) by misrepresenting the authoritative source of it, or misquoting people for character assassination purposes. these are things that can already be done without your tool, and in fact the first one was part of the decline of RSS the first time around. I don't think your tool needs to actively worry about these types of threats, at least not in its present state.

so, leaving aside the active-malice stuff mentioned above, there are two negative psychological elements to reshares on social media in general.

one of them is the gambling-psychology element of it, essentially trying to tempt people into seeking fame by optimizing their writing into something that others will want to reshare a lot. (our personal view is that fame is a trap; that's not specific to social media. sometimes it may be a tool as well, but it's a dangerous one.) this gambling-psychology concern mostly applies to the authors of posts, though it's helped along by heavy UI optimization and experiments, making it as easy and good-feeling as possible for readers to reshare.

the other is that reshares, especially of short posts that weren't meant to stand alone, decontextualize the source material. on some platforms they also make it very easy for the resharer to prime readers with their own, fake context, which can be a very powerful tool of harassment. this approach has been very effective at getting people who should be allies to fight each other, and since it's such a simple pattern to imitate, we're certain that lots of people doing it don't even recognize what they're doing as harmful.

the bottom line is that sometimes people are writing stuff that they want reshared, such as a plea for a certain sort of social change, or for help with their finances, or showing off their art.... and sometimes they're not. probably most people, most of the time, are better off when their words aren't reshared. however, when you do hit one of those scenarios where you want it, you really want it!

we don't know what this means for your tool, we're just sharing our general thoughts on this topic in case they're useful to you or others. we've said all this before, but perhaps not in one place.

we're still super excited about your tool because it does feel like a piece that will make it easier to build community on an rss-centric tech stack, rather than just individualist pontificating. we are probably going to end up using it :)

Thank you very much for your detailed replies, I really appreciate it!

The most overt examples of abuse that y'all described (i.e. outright plagiarism or deception) had occurred to me, though in its present state I agree that the effort required to do so is probably largely equivalent to the effort to do so manually. I'm now considering that maybe I should make it opt-in -- i.e. only posts where the button has explicitly been added could be shared -- and that is probably something I will do if the tool becomes widely used, though at this state that would likely just be another barrier to usability.

With regards to misrepresentation of posts out of context, though, that is perhaps something that could more explicitly address:

  • Currently, the link to the original post is already included, but it's unlikely someone will click on it if it has already been reproduced in full. Perhaps the reshare should by default only include some portion of the original post, with a "read more" link that goes back to the original?
  • In the same manner, I could make it so that the item's element always explicitly links back to the original post -- currently it does so by default, but it will link back to the resharer's link if provided. This has some benefits (i.e. if the resharer added additional comments) but also could fall into the same problem of reducing context.

The best way to approach these issues is probably giving more control to the original author over how their post looks when reshared... Definitely something I'll need to spend some time looking into. Thanks for giving your perspectives!