🇳🇱
Lists in mastodon were completely useless until we added the new features to QOTO for subscribing to remote instances local timelines and other subscriptions. There is a certain satisfaction in making a useless feature useful. It felt like wasted space before.
If you can't tell I'm super happy and excited about all the new features we added. So much fun getting to use them and knowing we are the only english speaking instance to have these features :)
@freemo Have you compared the domain subscription with https://mastovue.glitch.me or fedilab? Does it make sense to compare?
For me some toots I can see in those clients seem to be missing in "domain subscribed lists" at random. Can't see any pattern, but it seems to be a substantial part. I guess it's another obvious thing about the difference between how it's done on client side vs server side I'm misunderstanding...
@namark Id be curious to hear how fedilab implements it exactly. They would be useful to compare but I dont know enough about the fedilab internals to know how they compare.
@freemo I think they are just doing a simple API request like this:
https://fosstodon.org/api/v1/timelines/public?local=true
It seems to correspond to their output, and I can see the same discrepancy between that and my list on here.
@namark I'll dig deeper see what i find.
@namark With the help of Rob I figured out whats going on..
So you have two options.
1) is like you already did, use domain subscription. This basically fiters from the federated feed and gives you a timeline.
2) you can go to the properties on a post or in a profile and pull up the remote timeline. This will pull it up as a separate column and its content will be filled via the API. You can of course pint he column.
@namark FYI I mispoke the link to the remote timeline is only int he properties off a post, not the profile itself. Which is odd ill fix that, but it gets you the effect you want.
@freemo Thanks for looking into it! Unfortunately for me both methods yield the same result. That column's content is identical to the domain subscribed list(for those that had enough time to fill up), and still missing some toots compared to a direct API call, or the other two clients I mentioned. It's hard to catch on smaller instances, but for mastodon.social or fosstodon.org I can always see 1-2 missing in first 5-10.
@namark hmm thats strange. When i tested it earlier the remote timeline seemed to populate instantly and retroactively like the timeline API would suggest where as subscriptions started empty and filled slowly if at all.
@freemo yes, the remote timeline column is instantaneous for me too, but still missing toots, and once the list catches up, they are identical. So could be using the same method under the hood... or could be something down the line that causes the problem for both methods...
@namark So I tested this locally and my findings dont agree with yours.
I have had a list goign locally for tech.lgbt through subscriptions since the features was added 2 days ago. This is a very slow server without many updates it seems because in those 2 days the list has yet to update for me, so we clearly arent getting much int he federation pipeline from them.
However if i pull up the remote timeline I do in fact get a ton of toots from them over the time period I have had my list going. So it would appear the remote timeline does in fact show more content than the domain subscription, even if you give it time to catch up.
@freemo Snooping around a bit more, I was able to open one of the missing toots in QOTO's interface and star it. So can confirm It not a block (that confirms it right?). Also the toot appeared both in the list and in the remote instance column after that.
As far as i understand this code (I didnt write it so I may be getting it wrong) thats not hwo it works. Remote instances provide an API point that has the entire local feed (the public part). As far as I can tell when you view the remote timeline here by pulling it up via the properties as its own column then it does in fact fill everything in, not just things from the remote timeline, but there is a bug and it does miss some stuff I think.
What you describe does apply too but thats only when you do it through Domain Subscriptions a seperate but similar feature we provide that works through filtering the federated feed instead.
Maybe not, but Sorry for my ruding from nothing to relating!
( @freemo I want to be mixed for some reason I'm free! I also think same As mentioned by mewmew and namark, both of the above are the other server's "Timeline Viewer" functions to display only the TOOTs already listed on this server (I personally understand whether it was convenient for processing time @noellabo ). In Japan, There was history of "Timeline Viewer" https://translate.google.com/translate?hl=&sl=ja&tl=en&u=https%3A%2F%2Fja.mstdn.wiki%2F%E3%82%BF%E3%82%A4%E3%83%A0%E3%83%A9%E3%82%A4%E3%83%B3%E3%83%93%E3%83%A5%E3%83%BC%E3%82%A2 (by using API https://mstpubapi.herokuapp.com/timeline?host=qoto.org&type=local&count=40 etc may be the easiest to use now.). So I'm not too embarrassed in this matter (Rather, it is useful because you can see the status of only the TOOTs that have reached this server.). Maybe not, but Sorry for my ruding from nothing to relating!
@puzzl @freemo
@mewmew
The "subscribe" function does not make API calls to other servers. Subscribe to only posts delivered to the server by ActivityPub. Same as FTL. Therefore, the LTL of another server cannot be completely obtained.
Mastodon does not generally use APIs for communication between servers. APIs are used to resolve communication between specific server software and clients. The server only uses ActivityPub and simple HTTP requests to communicate with fediverse.
@puzzl @freemo @mewmew Mentions to @namark were missing. Look here.
https://fedibird.com/@noellabo/103540953078799925
https://fedibird.com/@noellabo/103540954372983881
@noellabo Thank you for explaining!
(By the way, As a client that can do something extraordinary "Timeline Viewer" with other servers, it has not been updated for a long time, but I like "Kurotodon" https://chrome.google.com/webstore/detail/kurotodon/fandjchmgmejjcjcedgeoileeibjndbb?hl=en )
Make sense to me. What @freemo was trying to figure out in particular is whether the option to view the local timeline in the "..." menu on the toot is different from the domain subscription. I'm guessing in this context it isn't.
@freemo I think I lied that I could reproduce what you described with tech.lgbt, I just got confused with bunch of old toots that looked like new ones. For me both methods show the same thing, If I disregard toots that happened before the list was created.
Certainly looks like to me it is calling the remote api for the timeline.
Here is the commit that introduced the functionality. I highlighted the line where we can clearly see the remote timeline is be called through the API
@namark @freemo @puzzl @mewmew This API call is only sent to your own server. Internal call. The explanation that the API was not used to realize this function required annotation.
If you consider WebUI as client software that accesses any server, you can get the real LTL by issuing APIs to remote servers.
Mastodon also allows remote servers to restrict access to the LTL without a token. Even in this case, the problem can be solved by holding the access token of the server in the WebUI.
@namark @freemo @puzzl @mewmew Mastodon's design has been carefully designed to prevent users from directly accessing external resources. Remote resources are cached by the server and the cache is served to the user. It is intentionally designed to synchronize the timing of accessing resources with the distribution, making access analysis difficult. Exceptions are activities you do yourself, such as favorites and replies.
In this case I think it would be very nice to allow the WebUI to access the remote timeline directly through their API. Though I think it is reasonable to say that if a remote server restricts this access then in those cases you would be prevented from viewing the remote timeline.
I guess if i want this feature I'll have to implement it from scratch then. Seems only reasonable the WebUI should be at least as functional as mobile clients.
@freemo @namark @puzzl @mewmew When accessing the API directly to the remote server,
When reacting to a remote status, you need an additional action to ask the server to fetch the remote status and get the internal status ID of your server.
The Content Security Policy needs to be set very loosely to view remote resources without going through the server.
Some of the security and privacy philosophies offered by Mastodon will be overridden, so you need to think and agree.
I dont think the web UI itself should directly call the remote API. Ideally the server would call the remote API for you. That would also ensure that instance level bans would be honored since the server will get rejected.
As such it wouldnt be possible in something like halcyon.
@freemo @namark @puzzl @mewmew Yes, there are some things that are difficult without going through your own server, such as block and mute processing.
The current implementation of Fedibird is a current design based on the ideas described above.
By the way, I have another idea for approaching a remote server. Please wait for the next function addition! :-)
Can't wait! We dont use fedibird as-is, but I do pull in your features and if needed modify, so appreciate it all the same.
For example QOTO has its local timeline unlike fedibird that eliminates it, we also added in local-only toots and a few other features. But I am very eager to see what else you add to fedibird and potentially pull it into QOTO, it has been a huge help!
Thanks again for all you do!
@noellabo By the way thanks for the help in explaining this!
@puzzl @freemo @mewmew The solution is a relay and a Federation bot.
Relays are the perfect mechanism for exchanging the LTL we just want.
Federation bot is an automated program that follows all users found on fediverse in the way that mastodon.host does. However, this is an overkill approach, as you get extra information outside of the public post. Not all users can be found and are often refused to follow.