Currently, if someone links to another threadiverse post in their post, it is seemingly handled as any other URL is and opened using the in-app browser. Instead, I suggest that such links be opened as posts directly, with the user having the option to tap the back button at the top left to return to the original post.
You must log in or # to comment.
Do you know if any of the other apps do this? I might reach out to one of the other devs to see if they have any suggestions on the best way to handle this. It should be possible, but maybe a little tricky.
Example posts are always helpful! The less time I have to spend tracking test data down, the more quickly I can move on to the next bug/feature.
Mlem dev here. You can use Lemmy’s
resolve_objectendpoint to get the data for an entity given a URL pointing to it.For example, here’s the request for this post: https://lemmy.world/api/v3/resolve_object?q=https%3A%2F%2Flemmy.ml%2Fpost%2F37416479
The tricky part is identifying whether a link is a theadiverse link or not. One solution would be to try the
resolve_objectrequest when the user taps on a link. If the request succeeds, open the link in-app. Otherwise, open the browser.The downside of that approach is that there’s a slight delay whenever you tap on a link while the app calls
resolve_object. To avoid this, Mlem stores an array of all Lemmy/PieFed domains in memory. If the link’s domain is in that array, we useresolve_objectto open it in-app. Otherwise, we open it in the browser. We build the domain list from data obtained from https://data.lemmyverse.net/.Another solution would be to look at the path of a link and see if it looks Lemmy-like. For instance, check whether it has
/postas the first path component.Neither of those solutions handle links that aren’t from Lemmy/PieFed, which may still resolve with
resolve_object. We decided that speed is more important that supporting those fringe cases.That’s helpful! I was trying to avoid building a giant list of known Threadiverse instances. I actually maintain my own crawler (https://crawler.blorpblorp.xyz/v1/instances.json), but filter out any instance with <20 monthly active users to keep the list small. I wonder if my list of crawled instances is complete enough to solve most use cases. Otherwise I might need to grab instances with <20 MAU.
Side note, if you are interested in hosting your own crawler instead of relying on https://data.lemmyverse.net/, you can fork my GitHub repo. It does the crawling as a free GitHub action.
Side note, if you are interested in hosting your own crawler instead of relying on https://data.lemmyverse.net/, you can fork my GitHub repo. It does the crawling as a free GitHub action.
Thanks, that’s super useful! We’ll have a look 👀 It would be great to not have to rely on third-party services like Lemmyverse that might go down for whatever reason
Here’s the example post that made me think to mention it. Arctic and Mlem both open the link within the post as a post in its own right.
On a side note, Mlem is able to load the image from that post within the app (albeit unfortunately failing to proxy it from i.redd.it and requiring the user to load it directly), while Arctic and Blorp don’t load the image at all. Perhaps that could be fixed too?
Post in Blorp:
Post in Mlem (initially):
Post in Mlem (after loading image directly):
Hmmm. I’m already doing some sketchy stuff to try and resolve images when there is an issue. I’m not sure if this specific issue is worth adding complexity to the app, unless you’ve seen this more than once?
As image-based posts are generally from communities unlikely to make my no-block shortlist, I’m not entirely sure how extensive the issue is, but a limited comparison didn’t turn up any other examples, so maybe the issue in question is specifically with how i.redd.it images are fetched?
I’d certainly argue that there are more important priorities than fixing a rarely-encountered image rendering glitch, but if it is indeed largely limited in scope to that one source, perhaps it could at least be added for review at a future point?
In terms of fetching media, I also think that employing proxies as Mlem seems to do for Reddit images and Arctic does for YouTube (via individuous) is a good option for privacy, but something I imagine would be more complex and less reliable, and probably shouldn’t hold back the implementation of more important features first.
I’m happy to utilize proxies that exist already. But I don’t want to build anything custom. I’m trying to keep my hosting cost down, as well as making it dead simple to host Blorp yourself (the web version). Currently, Blorp is made up of some static files and that’s it.
As far as current priorities, I’m want to
- Stabilizing the lightbox feed (when you click on an image)
- Overhaul private messages, as the current implementation is not very good
- Bring more moderation features into Blorp
- Explain better what features PieFed doesn’t yet support (e.g. PieFed doesn’t support comment searches)
- Work with PieFed to bring more of their features into the API so Blorp can use them (e.g. event posts, post polls).
Understandable about proxies; in regards to i.redd.it, I wonder if the issue in fetching images is the same one supposedly encountered by yt-dlp here?
Per this Reddit thread, it seems that Reddit has intentionally adjusted media hosting links to make it more difficult to load them outside of Reddit itself, but maybe something there would give a clue as to how to fix it in the same manner Mlem does?
