NodeBB <> Lemmy federation issue (re: nullable image/icon)
Technical Discussion
14
Posts
4
Posters
19
Views
-
evan@cosocial.ca I had no idea that was the case. That is very good to know and having it called out in some sort of best practices doc (an existing w3c explainer?) would be helpful :smile:
-
NodeBB v4.6.1 contains the fix so that if an avatar and cover photo are not set, they are not included in the ActivityPub actor data.
-
@julian @evan aside from potentially causing null pointer exceptions when you try to dereference null, using null is equivalent to just leaving out the statement in the first place. there's no reason to use null. the only time you'd need null values is if your schema required a certain key to be present but allowed the value to be nullable, which is generally a bad idea compared to just making the key optional. tony hoare, the inventor of null, called it their "billion-dollar mistake".
-
@julian @evan aside from potentially causing null pointer exceptions when you try to dereference null, using null is equivalent to just leaving out the statement in the first place. there's no reason to use null. the only time you'd need null values is if your schema required a certain key to be present but allowed the value to be nullable, which is generally a bad idea compared to just making the key optional. tony hoare, the inventor of null, called it their "billion-dollar mistake".
trwnh@mastodon.social said in NodeBB <> Lemmy federation issue (re: nullable image/icon):
> using null is equivalent to just leaving out the statement in the first place.That's not true, there are specific scenarios where having an explicit "no value" is significant vs "missing value"...
-
@julian if you give me any specific examples of when you would want to use null, i can recommend better alternatives. generally, it's always possible that there is missing information.
-
@julian love to see the reports of cross project colab!
-
@julian if you give me any specific examples of when you would want to use null, i can recommend better alternatives. generally, it's always possible that there is missing information.
trwnh@mastodon.social found one.
NodeBB uses
audienceto denote which audience an object (or context) belongs to.Posts and Topics in NodeBB can belong to no context at all.
nullwould be the way to communicate this, since omission might mean one isn't specified.Likewise, a Move(Context) where a topic is moved out of a category but not into another. You probably shouldnt omit
targetthere. -
@julian no, null is the same as nothing. what you want is more like [] (the empty set). in the case where you Move something without a target, you should be sending an Update instead.
-
@julian no, null is the same as nothing. what you want is more like [] (the empty set). in the case where you Move something without a target, you should be sending an Update instead.
@julian but more generally my question is, what practical application would you need to make use of an empty set []? like, a consumer encountering a value should do A, encountering a null or missing property should do B, encountering an empty set should do C... what is the difference between B and C?
-
@julian but more generally my question is, what practical application would you need to make use of an empty set []? like, a consumer encountering a value should do A, encountering a null or missing property should do B, encountering an empty set should do C... what is the difference between B and C?
trwnh@mastodon.social receiving a Move(Context) where target is null would tell NodeBB to move the topic to -1, uncategorized.
For those not supporting the catch-all bucket, deleting the context is ok too.
-
@julian so this is still in effect a Remove or Update, not a Move. if you wanted it to be a Move, you would instead have an "uncategorized" category whose id is /categories/-1 or something like that.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian so this is still in effect a Remove or Update, not a Move. if you wanted it to be a Move, you would instead have an "uncategorized" category whose id is /categories/-1 or something like that.
-
trwnh@mastodon.social receiving a Move(Context) where target is null would tell NodeBB to move the topic to -1, uncategorized.
For those not supporting the catch-all bucket, deleting the context is ok too.
-
@julian but more generally my question is, what practical application would you need to make use of an empty set []? like, a consumer encountering a value should do A, encountering a null or missing property should do B, encountering an empty set should do C... what is the difference between B and C?
-
@julian no, null is the same as nothing. what you want is more like [] (the empty set). in the case where you Move something without a target, you should be sending an Update instead.
-
trwnh@mastodon.social found one.
NodeBB uses audience to denote which audience an object (or context) belongs to.
Posts and Topics in NodeBB can belong to no context at all. null would be the way to communicate this, since omission might mean one isn't specified.
Likewise, a Move(Context) where a topic is moved out of a category but not into another. You probably shouldnt omit target there.
-
@hongminhee @2chanhaeng I see you already got some comments of this nature but was gonna point them out as well. Ibis is the farthest along but Xwiki was the first to add AP to a wiki that I know of. Also Piefed has an added wiki feature for every community but I don't think they federate that part yet.
-
Moving contexts (aka topics/threads) between audiences (aka categories/communities) should be something that can be communicated outward.
NodeBB is experimenting with using the Move activity to communicate this to other instances.
When a context is moved from one audience to another, the object and all of its descendants go with it. This is communicated with a Move activity with the resolvable context as object, and with origin and target referring to the outgoing and incoming audience, respectively.
An example Move:
{ @context: <... snipped>, id: "https://activitypub.space/topic/123#activity/move/1761362910015", type: "Move", actor: "https://activitypub.space/uid/1", to: ["https://www.w3.org/ns/activitystreams#Public"], cc: [ "https://activitypub.space/category/1/followers", "https://activitypub.space/category/2/followers", ], object: "https://activitypub.space/topic/1", origin: "https://activitypub.space/category/1", target: "https://activitypub.space/category/2", }The object https://activitypub.space/topic/1 doesn't necessarily mean anything to most implementors, so unless the object domain is yours, you are expected to resolve it to find the root object (and associated context if necessary.)
Would adding a new property like contextRoot pointing to the root-level object be useful for implementors?
If target is null, theoretically this could signify the removal of a context from its audience. null values are apparently a no-no in AP so Remove activity is recommended instead.
rimu@piefed.social and nutomic@lemmy.ml melroy@kbin.melroy.org I wanted to ping you all as I am interested in your feedback as I move toward drafting this FEP.
-
This does exist, Pleroma has the Message Rewrite Filters or MRF functionality. There's also ActivitySieve or ActivityColander I think it was called, which attempted to do similar.
I've personally been arguing that we need federation management via policies more akin to a firewall: https://writings.thisismissem.social/moving-beyond-the-false-dichotomy-for-federation-management/
