And it's a good thing too since post version 3 mastadon instances do not serve HTML text or images. It's all just a javascript application. The RSS feed is the only way to actually access the text of posts without executing an arbitrary application. It'd be nice if there was a "nitter" for twitter but for mastadon(s).
Mastodon (with an o, an often made mistake) has an API, which most alternatives (pleroma, gotosocial etc) also implement, partly. Several frontends, including extremely lightweight clients exist for this API.
Mastodon furthermore implements the whole server-server ActivityPub standard, which can be used for some actions, like following someone, just fine. This is a very well described standard.
Mastodon doesn't implement ActivityPub server-client standard, instead it has the aforementioned selfbrewn "rest" API. Which, IMO is a shame, and has caused all clients (mobile, web, etc) to rely on this nonstandard API.
Edit: the point being:there are several ways to get content from Mastodon, depending on usecase and needs. You really don't need to scrape or parse or load the JS cliënt.
> Mastodon doesn't implement ActivityPub server-client standard
To be fair to Mastodon, the main developer did give a reason for this.
> The ActivityPub Client-to-Server spec assumes a thin server and thick client. By which I mean, the client, like an e-mail app, has to download and manage most data from the server. From my understanding that's the only way to make anything like search or username autocomplete or even a notifications tab to work with the C2S at all. In my experience, app developers are generally not excited to do that kind of legwork, and we're entering the kind of P2P territory which comes with its own challenges like the ease of hopping from one device to another, or the fact that to have the same functionality in iOS, Android, and Web, you would need to recreate the heavy-lifting fundamental boilerplate in each separately. For that reason, I am not particularly interested in the C2S part of ActivityPub.
It seems odd to make some distinction between HTML or RSS and a JSON endpoint. If anything, the JSON endpoint is actually more human readable than the HTML or RSS output, you just have an "arbitrary application" that happens to understand HTML and RSS to display it to you. All of them contain the exact same data, just represented in different ways.
Firefox has a nice UI for browsing JSON, but Chrome will just give you a text dump. Ironically, Firefox also used to have a nice UI for browsing RSS feeds but they removed it awhile ago.
I've tried reading the JSON too but typically remember to append .rss to a user profile URL more quickly than I remember or type /api/v1/.../statuses?exclude_replies=true etc (or .json to the profile url if that instance supports that).
Both are vastly inferior and tedious ways requiring me to type a new URL. It is not controverserial to say the primary purpose of a web browser is to display HTML. Most URLs resolve to HTML pages. It's been this way for 30 years. Only in the last 10 has this radical new application view of the web been creating walled gardens on top of the old document model web. And that's mostly for commercial/profit-motive reasons so it's sad to see non-profit motive software cargo culting SPA only dev.
It also means post v3 mastadon is inherently incompatible with indieweb standards like webmention since there is no page to check for URLs.
>Ironically, Firefox also used to have a nice UI for browsing RSS feeds but they removed it awhile ago.
IIRC, (some) browsers used to have a feature that allowed you to browse a web page that had XML content, such as http://a.com/b.xml .
You could expand and collapse nodes. Or maybe I remember it as being for XML, but it was actually for RSS. After all, RSS is an XML format or application - is that the right term?
Thanks! While far more tedious than just being able to see HTML in a browser when going to a URL (expected behavior for the last 30 years), zygolophodon does seem like the least worst option. I've now installed it on my newer machines which have python 3.6. For older computers I guess I'll keep appending .rss to the user profile URL and and finding the relevant post by eye (or just ignore mastadon URLs).
The JS requirement still annoys me. Mastodon is a whole lot faster than Twitter, but it still can't compete with Nitter and that's just rather silly.
I'm fine with things like pagination and submitting forms being broken without Javascript, but at least make it possible to view a linked thread.
I've been running a Lemmy server or my own for a bit and I have to say, Mastodon just seems so incredibly wasteful. Lemmy's UI may be quite barebones in comparison but the server component runs a lot more efficiently while also providing actual HTML when you ask for content.
The interesting thing about this is that it’s evident that many people don’t use spell check. I find it hard to relate as personally I can’t resist resolving those red underlines.
There are many many third clients that can make use of Mastodon API and Activitypub. There are plaintext web clients such as brutaldon that probably have what you want.
Modern web browsers are JavaScript engines that also render stuff. I understood the resistance to running JavaScript 20 years ago, but today, I rank that up there with buying a cell phone but refusing to run 3rd-party apps. The web is JavaScript now.
I have JavaScript disabled by default and enable it on my bookmarks and when necessary on random new websites I visit.
I have no problem turning on JS for a web app. I understand Google Maps just couldn't really work how it's expected to without JS. Same for web email clients, or games, or office suits.
But if your "app" is just a progressively-enhanced list of posts (e.g., a blog), there is no justification for forced JS usage. Sorry Mastodon.
Running JS is a privilege for those with the computing power (or battery capacity) to spare, and turns the browser into the biggest risk vector on whatever machine that browser is installed on.
Or requiring it just to render images. Actually seen some sites that work that way. And these were simple company pages or personal portfolio sites, so no reason why the images could not be static(ally served).
