NodeBB <> Lemmy federation issue (re: nullable image/icon)
Technical Discussion
26
Posts
4
Posters
99
Views
-
nutomic@lemmy.ml reported a federation issue with a NodeBB instance and we debugged it. It turns out Lemmy is unable to handle actors who have
imageoriconset tonull.Lemmy is taking steps to handle this (source, source), and NodeBB will update its actor logic to omit properties without an avatar or cover photo set.
-
undefined nodebb@fosstodon.org shared this topic on
-
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.
-
@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 oh, another one.
Glitch-soc apparently lets you hide follower counts, and federates a -1. That works but
nullwould be a more explicit statement that the follower collection is hidden/not accessible. -
@julian leaving out the totalItems statement entirely would do the same thing. the problem is when you ignore the (lack of) information presented and synthesize your own.
you could also define a vocab term for "hidden" or "unavailable", although this isn't much better than leaving it out in the first place
-
@julian leaving out the totalItems statement entirely would do the same thing. the problem is when you ignore the (lack of) information presented and synthesize your own.
you could also define a vocab term for "hidden" or "unavailable", although this isn't much better than leaving it out in the first place
trwnh@mastodon.social leaving out totalitems is absolutely not the same as explicitly declaring a null value. You don't know whether the implementation just didn't send totalItems or whether it was omitted on purpose.
-
@julian what's the difference between "not sending" vs "omitting"? those are synonyms
-
@julian what's the difference between "not sending" vs "omitting"? those are synonyms
trwnh@mastodon.social not sent due to implementation differences, rather.
-
trwnh@mastodon.social not sent due to implementation differences, rather.
@julian there's no difference on the consuming side (and in many programming languages you can check for truthiness with something like `if x.get("totalItems")` which defaults to returning null if missing anyway)
functionally, you either have the information, or you don't
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.
-
@trwnh@mastodon.social said in Expanding collections on delivery:
> say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?Simple. My outboxes send a "not supported" HTTP tag 🤣
But I'm being facetious.
From a C2S standpoint I suppose that makes sense. Thanks.
-
@julian now remove the requirement. what do you do instead?
- if it has ldp:inbox, send an LDN
...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.
-
@julian i don't think it's "inferred", and leaving ambiguous cases up to inference in specification is typically called "unspecified behavior" ;)
say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?
- in all cases, if it has an `inbox`, you send an LDN to that id if you can.
- in case it's an as:Collection, you iterate over its items in theory and repeat step 1 recursively. (this is also problematic because it can be both paged+unpaged)
-
@trwnh@mastodon.social so collection expansion is mainly for when I am sending an activity to collections that I control?
Then I'm wondering why this needs to be explicitly spelled out and required because it seems to be inferred already from a UX perspective.
-
@julian there's probably a bunch of open issues on the https://github.com/w3c/activitypub/issues tracker regarding the problems with outbox delivery. those problems might be addressable all together, but it might instead make more sense to conceive of a sort of "LDN proxy" which handles deliveries instead (and holds your keys as an HTTP agent sending signed messages)
-
i would be fine with removing this collection expansion behavior from outbox delivery if it was decided that outbox delivery itself is problematic and should be removed -- probably in favor of the client being responsible for sending notifications, where the client can apply whatever logic it wants.
this is kinda what mastodon does right now as a monolith -- it is both the activitypub client (submitting to its internal outbox) and also the http agent for linked data notifications.
-
> 7.1.2
wrt inbox forwarding, this only helps when addressing collections of *someone else*, where the contents are private. for your own collections, unless you plan to deliver all such activities to yourself with the expectation that you will forward them (why didn't the outbox do it for you?^1), it doesn't help you.
^1: if the outbox doesn't have your credentials, then it can't do this. in this case, you or your client is responsible for deliveries, and the outbox only publishes.
