That's clever. I've been ranting on and off since 2017 about how the fediverse will suffer the same issues as e-mail. But I never thought about treating the posts as e-mails in order to use existing e-mail threading tools to get a better structure. Salute.
I've always been slightly surprised that it's so rare (verging on non-existent) for Twitter and now Mastodon clients to adopt either email-style or reddit/Slashdot-style threading.
i have been arguing since the days of ICQ that instand messaging could be done over SMTP. people yelled at me then that that would ruin email because it would be a different way to communicate that doesn't work well with email clients.
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.
I'm surprised that Mastodon doean't provide a RSS feed itself? Other Fediverse platforms seem to do that.
Maybe the author wanted more fine control, but still, it would make its solution a bit easier.
Fun fact! Your local instance creates a shadow account for remote users, which has a unique ID and a copy of the profile data, but is otherwise empty.
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.
> Bonus: I add another link to each toot that opens it in the instance of its author, where I have access to the full reply chain, of which my own instance often captures only a subset. A very simple solution to one of Mastodon’s unfortunate limitations that are due to federation.
I ... would not have expected this to be the case.
This is definitely a primary problem with Mastodon and other fediverse software. However, I will mention there is a problem with the idea of fetching replies from the parent post’s home server that makes it hard to solve.
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
13 comments
[ 2.7 ms ] story [ 12.8 ms ] threadthey 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.
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.
There's a feature request open for that: https://github.com/mastodon/mastodon/issues/18601
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)
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