>Servers MUST NOT publish incorrect usage statistics.
Pokemon GoToSocial enters the chat
Pokemon GoToSocial enters the chat
Timeline
Post
Remote status
Context
4
@silverpill I don't wanna pollute activitypub.rocks thread for some W3C orbiter to get mad, so here goes.
>I don't like "incorrect" here, but haven't found a better word yet.
"Intentionally skewed" or "intentionally incorrect" mean similar things. As far as I understand, you want to prevent the GTS way of crying about indexers all the time to the point of poisoning data. That case would be covered there. To be pedantic, a bug would technically be FEP-compliant since it is not intentional, but once the bug is reported, or maintainers are aware of it and refuse to fix it, it becomes intentional.
>There is a FEP about advertising capabilities using metadata (FEP-9fde), I want to discourage this practice
Do you have a valid alternative? Sticking fields into Actors is not it since those aren't instance-wide.
>On the other hand, I can't think of any good reason to rely on software.
misskey.io did exactly that when they wrongly thought Pleroma's MediaProxy fetching their millions of emojis was causing them issues (it was a different Pleroma issue). If you need to filter data instance-wide based on software version in case of buggy behavior causing you issues/known vulnerabilities allowing breakage of trust on the network like account impersonation etc. this can be very useful when the version is correct.
RE: https://mitra.social/objects/019c6d68-fa49-1614-56bc-525473060337
>I don't like "incorrect" here, but haven't found a better word yet.
"Intentionally skewed" or "intentionally incorrect" mean similar things. As far as I understand, you want to prevent the GTS way of crying about indexers all the time to the point of poisoning data. That case would be covered there. To be pedantic, a bug would technically be FEP-compliant since it is not intentional, but once the bug is reported, or maintainers are aware of it and refuse to fix it, it becomes intentional.
>There is a FEP about advertising capabilities using metadata (FEP-9fde), I want to discourage this practice
Do you have a valid alternative? Sticking fields into Actors is not it since those aren't instance-wide.
>On the other hand, I can't think of any good reason to rely on software.
misskey.io did exactly that when they wrongly thought Pleroma's MediaProxy fetching their millions of emojis was causing them issues (it was a different Pleroma issue). If you need to filter data instance-wide based on software version in case of buggy behavior causing you issues/known vulnerabilities allowing breakage of trust on the network like account impersonation etc. this can be very useful when the version is correct.
RE: https://mitra.social/objects/019c6d68-fa49-1614-56bc-525473060337
>"Intentionally skewed"
I will use it, thanks for suggestion! Yes, this requirement was inspired by GtS shenanigans.
>Do you have a valid alternative? Sticking fields into Actors is not it since those aren't instance-wide.
Sticking fields into "instance actors": https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md
>...If you need to filter data instance-wide based on software version in case of buggy behavior causing you issues/known vulnerabilities allowing breakage of trust on the network like account impersonation etc. this can be very useful when the version is correct.
You're right. I will mention this use case in the FEP.
https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md
I mean yeah, for capability detection on the instance. Pleroma already does something similar with the capabilities field in Actors for Pleroma Chats. But metadata in Nodeinfo can be used for different things. You could optimize federation based on Nodeinfo to know whether the instance you are about to POST an Activity to would even accept it thus reducing server load. Sticking your whole blocklist into your instance Actor is unwieldy and makes the JSON unnecessarily big.
Similarly, you can stick list of moderators/admins in there, for content reporting from remote instances so that a remote instance does not have to know about all of them before hand. And you don't have to know the special API to get them from all AP implementations. It is not just about capability detection.
Things like max post length can be relegated to /api/v1/instance and similar, those don't have to be in Nodeinfo necessarily.
>Sticking your whole blocklist into your instance Actor is unwieldy and makes the JSON unnecessarily big.
What's the difference between sticking it into instance actor and NodeInfo doc? Both are JSON documents.
>Similarly, you can stick list of moderators/admins in there
Exposing mods/admins is a valid use of NodeInfo, because this information is important to people who are choosing an instance.
If an ActivityPub implementation needs to determine where to send e.g. Flag activity, admin/mod actors could be listed in an instance actor. Different protocols for different purposes.
Replies
4
@silverpill You could add both to Actors, but I don't think it's a good place for such data. Especially in the case of blocklists, they can be rather large and there could be performance issues in some implementations, especially those that roll their own LD parsers for AP endpoints. And since the blocklists can be big, there is more bandwidth used for data that doesn't need to be fetched that often. An implementation might want to fetch the instance actor more frequently for some purpose, but Nodeinfo can be fetched daily at most, if not even less. It's more or less an optimization.
Moderation field in this case make much more sense in an instance actor than blocklists since it's small.
Moderation field in this case make much more sense in an instance actor than blocklists since it's small.
@phnt @silverpill instance level blocklists should probably be their own endpoint, and ideally paginated, maybe a collection page makes the most sense.
@django @silverpill An OrderedCollection could work as well, yes. As long as the order is specified. That way you don't have to send 30 requests for paginated Collections every time you want to refresh the list.
@phnt If bandwidth is a concern, you can separate the FEP-844e application actor and the actor that signs GET requests (which gets re-fetched often).
It doesn't even need to be an actor:
An application can advertise its capabilities using the
implementsproperty on anApplicationobject.
This object might not be an actor.
-----
>there could be performance issues in some implementations, especially those that roll their own LD parsers for AP endpoints
They saw it coming.