Skip Navigation

User banner

kopper [they/them]

@ ShittyKopper @lemmy.blahaj.zone

Posts
58
Comments
462
Joined
3 yr. ago

  • activitypub in minecraft, because i had nothing better to do with my life

    Jump

  • no

  • activitypub in minecraft, because i had nothing better to do with my life

    Jump

  • there is no "use case" here

  • activitypub in minecraft, because i had nothing better to do with my life

    Jump

  • Like having some portals or borders which lead to the next server

    you don't need federation to do that though... the server could Just™ send a packet to the client to redirect it to another server. minecraft for example already has this functionality and nearly all "large" servers make use of it.

    honestly all use cases people think of for federated (in the AP way) game servers just feel like an attempt to cram federation as a buzzword anywhere they can think of "because its the next best thing trust me", similar to many other bubbles (NFTs, AI)

  • activitypub in minecraft, because i had nothing better to do with my life

    Jump

  • i don't blame them honestly. there's no real point to having activitypub federation in a game beyond silly experiments like this. (the low latency needs of a game would absolutely require a different protocol at the very least, even if federation made sense which i doubt)

  • Fediverse @lemmy.world
    kopper [they/them] @lemmy.blahaj.zone

    activitypub in minecraft, because i had nothing better to do with my life

    brain.d.on-t.work /notes/a1rumsky1sd2m9mj

  • What happened to actor-relative URLs proposal?

    Jump

  • yeah no i seriously don't see how that one actually helps anything. maybe for the odd self hoster it could make sense but realistically it's way too under-defined (but then that's the norm for ap, sadly)

    let's say lemmy implemented it. ok. what now? my current account is still under lemmy.blahaj.zone. i still can't move to some other instance without changing my account's id and breaking all the existing object ids. i can move my posts between instances (or perhaps connect multiple instance software to the same actor, though a generic C2S server can in theory accomplish something of that sort without needing to alter other instances communicating with mine) but my identity is not any more portable than without it.

    actor relative ids requires everyone to anticipate being portable and set their account up with it from the very start. maybe the existing account migrations can be used to one-time migrate a non-portable account to a portable one, but you're still required to host your own account on your own "identity instance" yourself, and you are more or less stuck on that identity instance if it ever goes down without you sending the same account move activity we already have out. it's not as simple as taking an account from one instance and moving it to another.

    https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md is imo better at accomplishing the goal, and unlike relative URLs it has real existing implementations proving it's viable in the first place. but it has it's own downsides as well (severly limiting domain block effectiveness for authorized fetch enabled instances, no key rotation afaict, ...)

    as a side note, don't get too hyped up by feps. they have no power over anything and an existence of one does not mean anything for the future of the protocol. implementations are still the only ones making the final call on how the protocol actually functions (because real governance and "spec compliance" is anywhere between doesn't exist and being actively hijacked by threads via swf), and the only implementation that actually matters in terms of protocol improvements is mastodon.

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    rulesky

  • It is against the law to Rule.

    Jump

  • sorry i just had to

  • Are there any guides, tutorials, or documentation for how to start building fediverse apps?

    Jump

  • not much beyond "look at what other apps you're trying to interoperate with output and try to reverse engineer your way through". reading through the sources of other apps may be a good idea.

    some links that may get you started, picked from https://socialhub.activitypub.rocks/t/guide-for-new-activitypub-implementers/479 :

    and depending on which ecosystem you're targeting:

    counter intuitively, avoid reading the specs if you're looking to federate with existing software. the official specs are... extremely lacking beyond giving you the bullets to shoot yourself in the foot with (half of what little it defines goes unused in the real world, important things like "how do i know this activity is sent by the person it claims to be" is completely undefined (hint: everyone has more or less settled on http signatures).

    once you get something federating, you can then look in the specs in an attempt to learn the concepts in depth, but writing code following the specs will result in code that simply won't federate.

  • The Fediverse is Inefficient (but that's a good trade-off)

    Jump

  • A lot of it boils down to most fedi software not being "native" and only having federation designed more-or-less as an afterthought addition on top of a traditional centralized-ish system (even for ones that have federation from the get-go). Meaning you make assumptions like "it's fine if I deletes the replies of a post if the post gets deleted".

    This, combined with how much data you can't re-load and have to track as it comes in (e.g. nobody implements the necessary collections to backfill who liked or boosted what from it's source, so you have to track that implicitly through Like and Announce activities), makes it extremely infeasible to implement while keeping the same user experience. Hell, even reply collections needed to backfill missing replies are a rarity (though a lot more common than the others given Mastodon implements them).

    Additionally, people want the same user experience they're used to in centralized systems, like search actually searching through everyone, globally. This is something I believe AP simply isn't "intended" for. ATProto, for example, is much better in this specific regard (but comes at it's own hefty costs, as an implementor).

    I don't blame the implementors for doing things this way. IMO it's better to partially implement something like AP as an extension, as opposed to diving in head first into being AP-native. The standards are extremely vague and incomplete once you start looking below the shallow surface, and this way at least if a better protocol comes by migration (or multi-protocol federation) won't be too difficult compared to if your source of truth was the same AS2 data you federated, the way AP intended you to.

  • The Fediverse is Inefficient (but that's a good trade-off)

    Jump

  • Eh, I'd make the argument the fediverse is overly inefficient, way more than it has to be. (But that doesn't seem to be the actual point of the post, instead rehashing the same "distribution = good" thing without bringing anything new to the table)

    Here are just a few things that could be fixed without needing to centralize fedi:

    • A vast majority of instance software will store all old remote non-media data (that could easily be re-fetched when needed) permanently, even if nobody has seen it in years.
    • If you're lucky enough to be on instance software that backfills replies (GoToSocial, the Iceshrimp rewrite as of a few days ago, Mastodon in an extremely limited capacity), it will be done slowly and recursively, when much better alternatives that don't need to deal with easy-to-get-wrong recursion handing are possible. (There is work going on to improve this, but it may take a while for it to land on enough instance software to make a difference)
    • The obvious thing everyone harps on: Abysmal media caching defaults.
    • No batching of activities. And relatedly, all sent activities are individually re-signed for each instance on each delivery (to be fair, handling this in a privacy preserving way is hard)
    • No batching of fetches.
    • RSA, just to make the above signature situation even worse
    • Mastodon. Just in general. It's by far the most heavyweight fedi software I know of, running on a synchronous and poorly threaded tech stack that's is not very adequate to the fairly IO bound (when not using authorized fetch) and very concurrent AP use case. Running Mastodon for any instance less than ~500 active users is extremely overkill and you'd likely be suited with other, lighter, instance software if you don't need any of the features that are Mastodon exclusive (which there aren't that much of).
    • Pleroma database rot, an exemplar of why the C2S advocates' model of "store the raw JSON for everything" is a terrible idea (thankfully the C2S model hasn't taken off enough to be important)

  • The Fediverse is Inefficient (but that's a good trade-off)

    Jump

  • I mean, I'd say that all instances copying media by default, to be stored forever, is kind of unnecessary. (And as far as I'm aware Mastodon is the only one configured like this by default anyway)

    The largest instances? Sure. I'd say they have an obligation to not DoS smaller instances by simply hotlinking or proxying without any kind of cache. But smaller ones can get away with short lived middleware-level caches, and single user ones can often get away with hotlinking (oh boo hoo your firewalled IPv4 behind enough CGNATs to block any incoming connections got exposed)

    One idea I’ve seen floated around is to have some sort of cooperative CDN for instances. Let’s say four or five relatively kindred instances, make a commitment to last and pool their resources to maintain a joint CDN from from which they’ll get their “media federation” from. This would reduce costs and issues a lot, since by the very nature of the fediverse, if everyone builds their own caches most of those caches are going to be hosting most of the same content. Basically: deduplication, but the poor man’s version.

    https://jortage.com/ already exists, and the code behind is open.

  • How are Misskey and its forks doing?

    Jump

  • All other devs jumped ship. I think both Iceshrimp and Sharkey were launched by former Firefish devs (at least one of them was, Iceshrimp being a former hard fork of Firefish which was quickly rebased into a more up-to-date Misskey soft fork

    Iceshrimp (Misskey fork) did not rebase their version of Misskey. They're still based on the same Misskey v12 era code from Firefish and there's no interest in significantly updating the JS version (as it'd make migration harder) now that the rewrite is well underway and (in my potentially biased opinion) quite promising.

    [...] This is far from done which means it’s even farther from being daily-driveable.

    If you're on a single-user instance, and can limit yourself to apps targeting the Mastodon API, it's quite usable. The web frontend still needs a fair chunk of work, and moderation tooling required for larger instances are still not there yet. (But there's enough to fend off spam)

    Iceshrimp was designed for stability which is also why a number of Firefish features had been kicked out. It itself is on maintenance for as long as it will continue to exist, which won’t be that long.

    The only features kicked out from the Misskey fork were, from what I remember, post imports (which were broken and leaked DMs (Sharkey's on the other hand should work fine, as their implementation is unrelated to the Firefish one)), and the centered view in the web front-end. The rewrite may end up removing more features, it's still not exactly clear as more important foundational work is needed before decisions like that can be made.

    Sharkey used to be the king of features, but at the cost of reliability. Especially Sharkey’s Mastodon API implementation is infamously bad. The Sharkey community has been waiting for someone to step up and develop a completely new Mastodon API implementation for Sharkey for I don’t know how long.

    Sharkey's Mastodon API was I believe more or less a direct port of the old Firefish one. (And, yeah, it's not in a pretty state right now.) Firefish's implementation has since gotten replaced with the implementation from Iceshrimp some time after Firefish was handed off to Naskya (which may just be the only Mastodon API implementation on Misskey-based software that actually works).

    Also, the Sharkey devs lost a whole lot of community support when they collected donations for a server for Sharkey purposes and then took the money to set up a Minecraft server. Make of that what you want.

    This is way too much of an oversimplification that I would plain remove this claim altogether. All I can say is that Sharkey/transfem.social has had a change of ownership and things are more or less resolved now.

    And then there’s CherryPick. AFAIK, it’s a Japan-based Sharkey soft-fork in which a whole lot of Misskey and Sharkey issues have been fixed; don’t ask me for details, I only know this stuff from hearsay. Basically, CherryPick is Sharkey in good. Or in better.

    CherryPick is older than Sharkey, and Korean (from what I know, anyway)

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    the ruletainous landscape

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    sruleeptober

  • The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

    Jump

  • But these features were totally non-standard extensions right?

    that's the thing, everything in activitypub is a non-standard extension. hashtags are an extension. post visibility the way it's commonly done is an extension (more like a convention in that it doesn't introduce anything new, but still not written down anywhere official), the concept of an un-locked account is a convention (and the marker that marks an account as locked is an extension). pinned posts, marking images as sensitive, they're all extensions

    (surprisingly, this is the second time i'm writing this exact thing today)

    It’s weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.

    this has historically been mastodon. and they have put themselves in such a place that anything they do not approve of gets seen as a "nonstandard extension" and anything they approve of gets seen as a part of the standard. see the above reply.

    edit: additionally, emoji reactions are federated by the SECOND MOST POPULAR free/open AP software and has implementations in at least 5 other software families (not just forks of one software, entire software families). if they cannot determine a de-facto standard but mastodon can, is AP really an open standard?

  • The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

    Jump

  • this issue is a blocker for mastodon not supporting filtering remote posts by words (which would've helped with many spam attacks, which the pleroma family supported just fine for a WHILE via MRF, and more recently misskey has added support for)

    if you go to socialhub you'll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest. the most infuriating recent ones i have seen is the emoji reaction fep discussion and FEP-fb2a: Actor metadata both of which does this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY

  • The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

    Jump

  • Yeah, that is a shortcoming of the protocol. But it's necessary in order to be secure until things improve (and given this is AP, that's gonna be a while. People seem to love bikeshedding in circles instead of doing actual work)

  • The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

    Jump

  • Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.

    In the receiving side, if the object is untrusted (i.e. if it isn't signed or if it's from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy's implementation and not a protocol problem.

  • The two most upvoted comments on any Lemmy instance are on Feddit.dk, but you won't see them on your own instance

    Jump

  • I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see https://endlesstalk.org/c/tails@lemmon.website, which re-wrote posts from people (which is only possible if the posts weren't validated, or at least re-fetched from their origins)).

    There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).

  • rule

    Jump

  • skill issue

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    rule

  • Creating your own federated microblog

    Jump

  • i'm pretty excited for fedify since i'm unsure if there has been any other activitypub abstraction that feels as comprehensive as it seems right now (from a brief skim, anyway).

    one thing i had in mind ever since i first skimmed the docs some time ago is this:

     js
        
federation.setActorDispatcher("/users/{handle}", async (ctx, handle) => {

    i would really recommend you to NOT tell people to use handles here. i assume this is just naming and the framework doesn't actually require a handle there, but documentation matters and if you follow on the footsteps of mastodon, pleroma, lemmy, and friends everyone who follows your docs will lose the ability to change usernames down the line without more pain than it's worth (and yes, there are software out there that allow it right now! please do not build fedi software assuming usernames are immutable jsut because mastodon doesn't let people do it)

    just like how you wouldn't use a natural key in a database, you should tell people to use a surrogate key like an autoincrement id or a uuid on the actor IDs, as they're effectively permanent. while it may be probably fine for a quickstart thing like this to omit that, a lot of permanent codebases do start up by following these kinds of guides, and nudging people to do the correct thing when it's not that hard is always a good idea IMO

  • substrate rule

    Jump

  • yep, definitely. i just thought "hey wouldn't it be funny if two dudes just ate some undefined substance because it's cheap" and, uhhh, yeah

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    substrate rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    you just have no choice but to be that rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    be the ruleson

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    rulestone machine idea

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    yourule premium

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    dan rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    woag quirky ai rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    firule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    best rule according to AI

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    lebron "rule" jame

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    rizzkey rule

  • 196 @lemmy.blahaj.zone
    kopper [they/them] @lemmy.blahaj.zone

    bought him at the rule market

  • Unpopular Opinion @lemmy.world
    kopper [they/them] @lemmy.blahaj.zone

    most communities should implement an explicit "no US politics" rule