Deconstructing the Mastodon Client
blog.khinsen.net
blog.khinsen.net
they were sort of right of course, because it's the client that makes the difference, not the protocol.
and deltachat today proves that i was right all this time.
it's really just about sending and replying to messages.
you have text, voice, video and physical messages.
they are synchronous or asynchronous.
instant messaging, as much as it is instant is still asynchronous because i can reply to a message hours or days later. they are only synchronous in the same way as an immediate email reply is synchronous.
maybe IRC can be considered only synchronous because it doesn't feature an option to reply to specific messages, so there is no threading. just a linear stream.
for asynchronous messaging each protocol (like SMTP, XMPP, mastodon, NNTP, etc) needs to be implemented but only a single implementation of the backend to manage the actual messages is needed because most features of all of these protocols can be mapped to the same primitive in the backend/database.
each message has a sender, recipients, the content of the message. a parent messages that is being replied to. some messages further have a body or attachments. and some have a subject/thread topic.
that alone covers the majority of messaging protocols out there.
There's a feature request open for that: https://github.com/mastodon/mastodon/issues/18601
Just to add: You need to be on the original URL, so A-instance.com/@B-user@B-instance.com.rss won't work, it must be B-instance.com/@B-user.rss
I haven't seen this documented anywhere and it cost me about a day of effort when I was building a mastodon bot. If you naively try to fetch content from a remote user replying to a post, you won't find anything. You have to hit the remote instance's search API and pass their profile name in. Which is frankly insane.
I ... would not have expected this to be the case.
However, as per https://github.com/mastodon/mastodon/discussions/22608#discu..., I can see how it ended up that way and while it'd be nice if something triggered an on-demand fetch as discussed by other people later on, that can be added Later(tm).
The primary idea being that a user trusts their home instance, but don’t necessarily trust other instances.
If you fetch replies from another server, you are trusting that server to send you real, valid replies, from other servers. You could verify the replies, but this would be an expensive operation to do automatically.
As such, a malicious server could create phantom replies that don’t actually exist, and your trusted, home server would serve these to you. Currently, your home server only shows likes and replies it can validate (it heard it from the server that did it), but once you trust another server, you add a unnecessary middle man for some extra convenience
Depends just how dedicated you are to emacs, really...
(You certainly _can_ run emacs on both Android and iOS, though the user experience may be... not what you'd want)