🇳🇱
# Remote Timelines
I wanted to take a minute to explain QOTOs Remote timeline feature, specifically the new aspect we just released on the advanced interface: Domain Favourites.
This feature allows you to pull up a column which is identical to the local timeline of a remote instance, thus addressing the need for users to have multiple accounts across multiple instances. You can be here on QOTO and see the remote timeline as a separate feed just as if you were on the remote instance itself! For example attached to this post is what the Koyu.space remote timeline looks like from QOTO.org.
**Note:** This feature can not and does not bypass security permissions. If a user has blocked you you wont see that users posts in the remote timeline either.
There are several ways to pull up or switch between remote timelines, and you can have several remote timelines up at the same time or even combine them in a single column.
One way to do this is with the QOTO lists feature. Here you can create lists that are either collections of people you wish to follow in their own timeline, or a list of domains where you wish to follow the remote local timeline of the whole domain. Create the lists you want then open your lists and switch between them to view the various timelines you define.
You can also go into your settings and under preferences there is a subsection called "Favourite domains", you can add domains there as well. If you do this the domain will show up on the main navigation bar and you can select it with fewer clicks than through the list menu. There is also a Favourite Tags section in preferences that works much the same way.
You can also pull up the remote local timeline of an instance from a posted status itself. Simply click the three dots on a post from any user from the desired domain and one of the options will be to open the remote timeline for that domain.
That is all there is to it, enjoy!
@freemo Yeah, presumably individual clients will support different features — that's one of the great benefits of choosing your own client.
The only worry I have is that if each instance implements "remote timeline" a little differently, every client needs to support every implementation. Most projects don't want to support every idiosyncratic thing on every instance, but would be happy to be "fully featured" clients if there's wide adoption of a non-standard feature.
I'm curious to know if you are developing /implementing this stuff in a siloed way, or if it's part of a broader "Mastodon+" type effort that is likely to be worth clients' effort to support.
@freemo Though I'm fine if it's not, it just means that I'm less likely to be able to take advantage of the features in some scenarios, which is not necessarily a big deal.
@pganssle Remote timelines are already supported by all servers in the sense that there is a public standard API call that almost all servers implement that let you pull in their local timeline. So it is a standard feature.
What isnt standard is if or how the client actually lets you use it. Which has less to do with standards. Obviously if it weren't standard we wouldn't be able to implement the feature on QOTO in a way that you could pull in remote timelines at all (as the remote server needs to have a standard API point to pull from).
Most web clients dont support this feature, and some mobile apps do and some dont. But the implementation is standard and well adopted so should a client choose to implement this feature there would be no need for them to implement multiple variations to accommodate non-standardization.
As a general rule all the features I implement are as close to a standard as is available and we only deviate from standards in ways that either 1) enhance the standard without breaking it or 2) when there is no standard at all.
Rich-text/markdown posts, remote timelines, local-only posts, and in fact most of our features, are all well standardized. Even our quote feature, which doesnt have any sort of standard in ActivityPub or mastodon world, was based off the closest thing to a standard there is, namely, the way misskey does it (which is the only server that does it). In that case it is also rendered in such a way that is backwards compatible so clients that dont support the feature still can render the post in a sane way.
@pganssle depends, somethings yes, somethings no...
Any of this can, in theory, of course be supported by mobile apps if they wish. It is int he API itself so its all there. some things we will get out of the box as they are already implemented and supporters, others features not so much.
So take the remote timelines that I just posted about. That is supported out of the box by some clients, I think fedilab is one of them. Other clients don't have it implemented at all. It really depends on the client.
Rich text is another example. Many clients do support it and yes it uses a standard to encode the rich text (just basic html actually).. but some clients specifically strip formatting despite this.
In the end it depends on the client and what they want to support more than it depends on the standards it seems.