you can disable the webpage and unauthorized API if you so choose. mastodon and pleroma/akkoma provide these settings. gotosocial hides all posts with an unlisted visibility from public pages.

authorized fetch only provides protection for activitypub, it’s just a single component of a layered stack of protection you can enable depending on your exact threat model.

the privacy threat model of Lemmy is significantly different from a microblog, which is the current target of threads.

(also have none of you heard of consent?)

cc @FaceDeer@kbin.social this reply also applies to your reply

no, not really.

i have attempted to build my own federated stuff (none of them actually federated “in real life” though) so i did read the specs but quite a lot of these are from my memory and if there’s anything i know is that my memory fuckin sucks lol

Which could still be millions?

sharedInbox handles this.

mastodon.social sends a single federation activity to www.threads.net’s sharedInbox. threads’s internal systems handle all the visibility and routing to followed users and whatnot. the same thing happens in the opposite direction for threads->mastodon (or whoever).

now in theory this is an optional part of the specification and you can in fact send one activity per person if you really want to, but considering how widespread it is (and how relatively easy it is to implement) you’d have to be intentionally and explicitly malicious to not use a sharedInbox if the remote server indicates it supports it.

just want to clarify something:

However, the way that activitypub works, the outgoing data is publicly available. Defederating with Meta doesn’t prevent that,

there is a technical solution to this in the form of authorized fetch: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

mastodon implements it, pleroma/akkoma probably implements it, pixelfed implements it, firefish and iceshrimp implement it (sharkey has a PR implementing it opened just today), gotosocial not only implements it but enforces it, with no ability to turn it off

notably, none of the threadiverse software implement it (not even the bare minimum required to federate with instances enabling it), and no software other than the aforementioned gotosocial enable it by default.

they will have an excuse to do it openly instead of trying to do it secretly and inevitably getting caught

considering most Minecraft mods directly mess with the Minecraft code as opposed to going through a well defined API (forge and fabric only provide so much) you can’t really make that work without outright stealing Minecraft code

the best you can make would be resourcepack and datapack compatibility. maybe whatever molang stuff bedrock’s up to

if you were to focus this on just Lemmy itself as opposed to the wider fedi (“Especially given that there was just an update allowing for individuals to block instances they don’t like” implies that’s the case) you already have nothing to worry about as you encountering a threads user here will be even slimmer than encountering a mastodon user.

threads is primarily targeting the microblog/personal side of fedi. the incentives and privacy expectations are quite different compared to this side of fedi

re active users: they’re a large open registration instance, they likely have a fair chunk of twitter people who joined during one of the many migrations and decided not to stick around.

how will this deal with communities and instances having different rules and “culture” of their own?

oh, and which community’s moderators are going to have permission to moderate the comments section?

I have not seen a clear answer to either of these questions on any variation of this proposal. do y’all see every community as the same thing with a different domain at the end?

there was a fdroid client that did something similar using mastodon and hashtags but I can’t remember which one it was and if it’s still doing that

so, are you paying for it?

I didn’t tested non-followed community, but the bot works with mention event instead of comment. But still not sure, I’ll test this one 🙏

oh, I meant for the actual post watching part, summoning via mention should work without any subscription

in theory as you operate both the server and the bot you could modify lemmy to tell the bot when a new comment hits a thread instead of polling, which would be more efficient (but definitely harder to do!)

also does it handle the case where nobody from your instance is following a community? to make sure you get all the replies reliably the bot would need to subscribe to each community it’s watching a post from

that said, great work. I may end up using it if I don’t end up forgetting about its existence :p

.world is a newer gTLD whereas .ml is a more well known country code TLD. whatever auto linking code the lemmy UI uses likely just isn’t up to date with all these comparatively recent TLDs

https://fedidb.org/software/iceshrimp is a thing, and there are several general purpose instances such as fedia.social and iceshrimp.social (which isn’t anything official despite the name)

not having an (open) flagship is, to the best of my knowledge, an intentional choice as moderating it would take time away from development

I personally find the development to be more “sensible”. firefish bungled up their flagship with a (imo) failed transition to scylladb and hasn’t been doing much of importance since then (they changed the boost icon to a rocket though!)

compared to that, iceshrimp rewrote their mastodon api compatibility layer to the point where it may be the most compliant one among misskey forks, uncovered several perf bottlenecks (one really big one related to word mutes since fedia migrated over), fixed the http signature security vuln ahead of firefish (and provided the patch to them, which they didn’t put in a stable release for something like two days even after merging)

quite a lot of firefish instances seem to be migrating over to sharkey for similar performance and stability reasons, but if you like the firefish UI/UX compared to the “classic” misskey one (or want a smoother migration path from firefish that doesn’t involve a major version bump) then iceshrimp is the one to check out imo

one of the misskey forks. imo “vanilla” misskey is lacking a fair bit of essential stuff (post editing being a giant one)

the most interesting ones to watch for now are iceshrimp (misskey v12 hardfork based on an early version of firefish, mainly focused on backend tech work compared to new features) and sharkey (misskey ”v13” softfork, aimed at qol changes and other feature work while keeping up to date with misskey itself)

akkoma is alright if you need something light on resources but I personally can’t get used to it’s interface

and mastodon is just… too bland in comparison to both

They aren’t forced to do anything. Manifest v3 is just a part of the WebExtensions API (which is not a standard and is really just “whatever Chrome does except we find/replace’d the word chrome to browser”) which both Safari and Firefox chose to implement in order to make porting of Chrome extensions easier.

Before that, Firefox had a much more powerful extension system that allowed extensions quite a lot of access to browser internals, but that turned out to be a maintenance nightmare so they walled those APIs off (not a coincidence that Firefox started getting massive performance improvements after that, and extensions stopped breaking every other release) and decided to go the WebExtensions route. I have no clue what Safari was up to but I think they implemented it after.

If they don’t implement Manifest v3, extensions that want to work across multiple browsers need to support both the older Manifest v2 and the later Manifest v3, which would be a burden not many extension authors would want to bother with, which would make them just say “yeah we’re not supporting anything outside Chrome”. Firefox avoids this problem by extending the v3 API to allow for the functionality necessary for powerful ad blocking Google removed in v3 (webRequestBlocking) while also implementing the new thing (declarativeNetRequest) side by side, so extensions that want to take advantage of the powerful features on Firefox can do so, while Chrome extensions that are fine with the less powerful alternative can still be ported over relatively easily.

Firefox does have it’s fair share of extensions on top of the WebExtension API already (sidebar support for one), so adding one more isn’t too big of a deal.

ActivityPub does not govern how user handles work. All AP actors are defined by their IDs (which in Lemmy’s case happens to be the URL their profile is hosted in, which is a mistake as you cannot change your username without breaking federation, but at least Lemmy isn’t alone, both Mastodon and I think *oma family of software do the same thing)

AFAIK the @username@instance convention is Webfinger’s doing, and (to the best of my very incomplete knowledge) the convention of “preferredUsername @ the hostname of the object ID” is a hack Mastodon pulled that got adopted as a de-facto standard (as is quite a lot of other things in AP).

You also can’t reuse a domain between software installations (some exceptions apply when migrating between software of the same “family tree”, e.g. migrating from a mastodon instance to glitch, or migrating between misskey forks) due to how federation works. Hell, reinstalling the same exact software can break federation if you wiped your database in the meanwhile.

Some software offer a “split domain” option where the software itself is installed in a subdomain like mastodon.example.com but with user handles on a separate domain (usually the root domain, like @example.com) but I am not too sure on the reusability of that, and it’s not an easy thing to implement (Lemmy won’t deal with that correctly and will always use the full domain for anyone on a split domain instance). There are also a handful of software (like Takahe) which let you “bring your own domain” so to speak.