Seems more like a genuine feature to me.

I don’t know how many requests I’ve seen for Lemmy apps to be able to swipe between posts in the feed.

Seems that’s basically what they’re doing here.

But also, gesture navigation is terrible, I hate it, and always turn on 3-button navigation when I get a new phone anyway.

I shouldn’t say this, but whatever: It’s a “troll” tactic to do that since mods/admins can’t ban with content removal if the account is deleted (unless that’s fixed in .13?) . Admins can remove the deleted flag in the DB for the user and then do so, but mods can only remove items individually. Not that any of these necessarily warrant removal on their own, but not doing so in this case encourages this kind of “hit it and quit it” behavior, and this user is clearly ban evading.

I’m not saying this as an instruction manual but merely as a statement of fact about how stupid Lemmy’s behavior is with regard to deleted accounts.

They’ve had many, many alts over the last 6+ months with the same posting pattern. Not one has been marked as a bot.

Ok, I just gotta ask: what is your motive here?

You get banned every other day for spamming out a massive number of posts. And you just make a new account the next day, start the exact same thing again like…you’ve learned nothing?

I’m tired of my feed being an entire page of just you, and I’m tired of blocking you. Can you not just post things at a normal rate?

but I send you a PM

Oh, sorry. One of the new features in this dev branch is the ability to disable PMs and mentions. I’ve been running with those turned off. Seems like that feature is working lol.

I turned DMs back on and found the message - will try to join here when I’m back on desktop. Dunno how active I can be right now, but I am eventually going to start on Piefed so would be nice to have a sounding board.

Some of the devs are already working on shared logic/libraries between apps.

Nice!

Oh, I meant just if the instance isn’t know, I thought resolving would make it “aware” of that instance. I could be wrong. But yeah, the instance would have to federate with the other one for it to be able to resolve, though. e.g. it won’t resolve an object from an instance that is on the current instance’s “block” list.

I believe you can, yeah, and I also think that “bootstraps” that instance to yours if it doesn’t already know about it. But in that case, the way I have the search written, it’ll “fall back” to regular search which also does resolveObject. That just takes longer.

The ap_id check is just to short-circuit that behavior to avoid the lengthy, often unnecessary, search and quickly redirect you to your instance’s local copy.

Have had that working for about a week now, and it’s pretty nice. Please do steal this feature lol.

At startup, it calls /api/v3/federated_instances and stores the result to a lookup variable. Then I’ve got a couple of helper functions that accept either an instance ID or a domain name which looks them up from the lookup variable.

Email on your own domain: Yep, super easy.

Email from home IP or from the IPv4 you get assigned with a VPS: Super difficult

I think you would be better served by checking for the Link header

Can’t really do that, client-side, in a browser application. CORS is a perpetual cockblock (though I understand why it is), and I’d rather not make an internal API endpoint to do the lookup.

The application polls Lemmy’s getFederatedInstances API endpoint at startup, so it has a list of every activity pub server your instance knows about. That’s the first and primary check for the URL that’s being searched.

The second check is just to rule out non activity pub URLs that point to a federated instance (e…g. https://lemmy.world/modlog, https://lemm.world/pictrs/image/blah.webp, etc).

Goal isn’t to “catch 'em all” but to catch the most used ones. If there’s one I don’t account for, either by omission or because the federated platform didn’t exist when I made the patterns, then it will just fall back to a regular search which also includes trying to resolve it as a federated URL (which is the current behavior in all prior versions).

The goal is just to simply short-circuit the search behavior if the query is a known ap_id URL in order to avoid a lengthy search process and quickly redirect you to your instance’s local copy.

I’m making an “omnisearch” box.

Paste in an AP_ID into the search field, and it auto-resolves it and redirects you to your instance’s local copy (which is very fast) instead of going through the whole search process (which is slow). To prevent false positives, I’m matching the various ap_id formats and only doing the resolution on those; anything else gets passed to search.

Anything else that falls through the cracks just gets passed to search as usual (which also does a resolveObject lookup).

It’s to make life easier.

We’ve had this discussion :)

This application is written against the Lemmy API. It only speaks API. Eventually it’ll speak Piefed API as well, but right now, only Lemmy API.

Lemmy and Piefed only do server-to-server Activity Pub and not client-to-server AP. Clients have to use the API to interact with them. This is a Lemmy (and eventually Piefed) client.

Cool, thanks. I was close with /user guessing from memory.

I think the /users/.../post_id will be sufficient. It just needs to know that the given URL is an AP_ID before passing it off to the API call to resolveObject. Since it already knows instance.domain.tld is a federated instance, it just needs to see if the path is an AP_ID or the HTML (or something else). Thus, I don’t have to parse the whole thing, just check that enough of it matches.

Thanks!

I’ve got an indicator row between above the comment text and the username (shows things like “deleted by creator”, “banned from community”, etc"). I suppose that could indicate whether the item was altered by a user filter.

But now I’m having second thoughts about this whole idea. Originally, I felt validated because I had kicked the idea around already, at least as a joke. But now I’m remembering YPTB, Fedi-drama, and similar communities exist and there are frequent flyers there who have nothing better to do than present things out of context and stir shit up and how this would be like giving them a loaded weapon.

Lemme (re) think on this.

What it does now (well, in the dev version), is evaluate the whole comment for various rules you can set. Here, I added a keyword regex filter (words|phrases) and applied it to the “Lemmy Apps” group.

This is how your comment shows up when it hit on those keywords:

When content is filtered, I don’t even let it show the creator (because sometimes you just see a name and you know it’s gonna be something braindead lol).

So I feel like that takes care of the “entire comment” portion of your idea (or at least that’s as far as I’d want to implement it). If the comment hit on any other policy rules, those would also show up in the list you see.

For the replacement text, I’m taking WizardBeard’s advice (below) and would somehow visibly identify that the original text has been modified by a user preference. Not sure how, exactly, I would do that. Maybe strike-through the original text and insert the replacement string italicized, in a different/larger font, or something like that.

Good morning Hello.

What’s up? I am not a person worth talking to.

The only complication would be that the indicator method, whatever it may be, has to be valid markdown and, thus, could theoretically be something the original person could have said.

Filtering policy editor looks like this (this is scoped to a group, so the “Communities” tab at the top is hidden):

But yeah, your other points are valid. Anything replaced needs to be indicated / highlighted / otherwise marked as not the original text.

I think I could pretty easily shim that into the filter policies in Tesseract (that’s the big project for this upcoming release). I already have customizeable regex filter lists for keywords, but those only set the “filtered” flag if they’re detected and return the list of regex patterns that were matched.

Since the filter policies can be either global or per community group, you could get pretty granular with it. I’ll look into it and see if it’s feasible to shim in.

I jokingly thought about adding something like that already.

Basically:

(^Paywall(ed)?$) -> I'm going to contribute nothing to the discussion except whine that you didn't cater to my laziness and make my laziness everyone else's problem until someone else replies with an archive link I could have easily gotten myself

I thought the feature was too absurd to flesh out, but if there’s interest, I’m open to adding it lol.

Good points.

I don’t have a full plan yet (just the general idea of a plan), but when I start the journey to Piefed, it’ll probably be from the ground up or very close to that. I already need to update the codebase from Svelte 4 to Svelte 5 which is a pretty big job due to the fundamental and breaking changes between those two versions.

The components that make up Tesseract (posts, comments, sidebars, everything) are also all heavily tied to Lemmy’s type definitions. To support Piefed, I’d have to de-couple the components in the code from Lemmy’s type def and add in an abstraction layer (both for future-proofing and to make it possible to support both if I wanted to).

Yeah…I’ve had to do a LOT of work client-side in Tesseract to give Lemmy half the features Piefed has. Eventually I’m gonna start targeting Piefed, but there’s some under the hood stuff I’m waiting to be resolved before I embark on that voyage. Mainly, I’ve heard that the main Piefed experience and the API are not 1:1 and not everything is exposed in the API. :(

It doesn’t now, but I’d be willing to add that to Tesseract. Seems easy enough to implement.

Edit: It’s not fully plumbed in yet, but the settings to configure it have been added to the filter policy framework. Will probably also do a similar setting for comments. Shown enabled here, but disabled by default, naturally.

Edit 2: Plumbed in and working now in the dev build. Can also completely hide those, but that doesn’t exactly work for a screenshot.