NodeBB <> Lemmy federation issue (re: nullable image/icon)
Technical Discussion
8
Posts
3
Posters
2
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 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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian I forgot, why do you want to delete a context? If it's your thread, isn't it enough to just Delete the top-level post?
-
mradcliffe@nokoto.org apart from the technical details, this approach also is extremely easy to explain to laypeople.
"Follow who this person follows" :heavy_check_mark:
-
I think that my comment on GitHub that Group Actors acting as Starter Packs really comes from how I approach my social network.
I rely on my friends and peers to discover new topics and meet new people.
Friends and peers as Starter Packs work great on a small microblog instance like Mastodon, Misskey, or Sharkey because the federated feed/bubble lists topics written by the amazing people that they are following. This approach is ideal for small instances, but flagship, large and relayed instances make it much harder as the topics are much too diverse.
When a small instance I was part of shutdown, I was really at a loss because I relied heavily on that feature without following people myself i.e. I'm lazy. And so to figure out who to follow, I went back to my peers’ and friends’ following Collection. Note to self, I need to remember to continually discover more people from people I follow now that I am on my own single-actor instance.
This is why I come to the conclusion that people are Starter Packs. Or in other words, Actors are Starter Packs. And more specifically, anyone or thing with a publicly-available following Collection is a Starter Pack.
But making a public directory of everyone is not a good idea and discoverability is hard.
Starter Packs should be (Group) Actors because
Consent is built-in with the Follow Accept/Reject.People that want to explicitly allow followers already have this option.Implementations should use Mastodon’s discoverability property to also limit who a Starter Pack may follow.Revoking consent is mostly built-in with either Remove Follow, Block Undo, or Reject Follow.Discoverability is built-in:The following Collection is available.Group Actors can make posts when their following Collection is updated.Amazing UX designers can make the following Collection more usable in their software.Starter Packs that are used in bad faith can be defederated like any other bad faith Actor or instance.The barrier to implementation is much lower than tacking on anything new to the specification.
-
Currently I am grappling with the specifics behind how to federate out the deletion of a topic in a category (or in ForumWG terms, the deletion of a context from an audience.)
For those unaware, a context is essentially an OrderedCollection containing all objects within its purview.
Deleting a note or other object is easy. If you are same-origin as the object, you Delete(Object), done.
Deleting a context is more difficult... you can't rely on other implementors to store references to your contexts, since it is essentially meaningless to them. Furthermore, if a context is deleted, then when a Delete(Context) is federated out, receivers will have no idea what they're seeing, will try to retrieve the object, and find a 404. So it doesn't even work at all.
Even worse, you can't really delete other peoples' contexts (or for that matter, their content) since you're not same-origin.
Finally, I realized I'm looking at this the wrong way — I'm not deleting contexts, I'm simply removing them from an audience. Remove works perfectly fine when the context continues to exist (as it can be referenced and duck typed). Remove also works for remote content; the same-origin check applies to the audience you're removing from.
If you're deleting a context, you have to be the same-origin, and you really should just federate out deletion of the local members in that collection, via regular Delete(Object).
I suppose federating out self-destruction of a context would be the most complete but it is quite difficult to do when it is no longer resolvable...
-
Yes I'm fine with that. It doesn't make much difference in the end.
-
Thanks Rimu. Will give this a shot.
Upon reflection, since Deletes aren't wrapped in an Announce, then I would recommend that any Move activity we use not be wrapped in Announce either.
-
@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.
