🇳🇱
# 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!
@mur2501 Well you are always more than welcome here. Luckily you dont **have** to use the remote timeline feature :)
@freemo
The problem remains that I will lost all my posts here 
@mur2501 All your posts yes, though not lost they would be at your old account. But you can keep your follower count (not just the people you follow but hose who follow you), as well as your block list and other stuff. So you really wont lose much, its your followers that is most important.
@freemo
Posts are also important man 
Cause I have 2 alts already but due to the losing posts shit I don't shift 
@mur2501 To each their own.. But Id say no one is looking back at posts you made from more than a month ago typically.They are preserved though none the less.
@freemo
Well no one does but I do look back at my posts alot
@mur2501 You still can if they are on a remote account. Like I said they dont get deleted :) but yea no worries, I understand your reluctance.
@freemo
Can I still keep logged into this account after shifting it?
@mur2501 Sure, it wont lock you out of your account entirely. It will just move your followers to the new account any anyone going to your old account will be told that you have moved and where to find you.
@freemo
That's good I shall shift my account then. What's the char limit on your instance?
@freemo
Wait your instance is pleroma?
@mur2501 No we are a fork of mastodon with significant features/code changes added on top.
@freemo
I see Qotodon 
Wait you have cat emojis na?
@mur2501 We do, and I will happily add any emojis you find we dont have.
@freemo
Specifically these two 
@mur2501 We do now: 
@mur2501 Check out https://qoto.org/about/more for a list of all the extra features we offer as well as other federated services we offer.
@freemo Awesome improvements. Is this stuff standardized enough that it could be supported by mobile apps? Probably >50% of my browsing fediverse is done on Tusky or something similar, so I miss out on some of the custom features of the qoto instance.
@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.
@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.
@freemo Glad to see Qoto always on the front-line of new features.
@Vectorfield Trying to keep the feature set useful too :)
@freemo
I want to get away from my instance