Implementing postingRestrictedToMods
Technical Discussion
6
Posts
3
Posters
15
Views
-
Hey pfefferle@mastodon.social nutomic@lemmy.ml, I'm looking to integrate support for
postingRestrictedToModsI see some discussion here:
It's a little specific, but even so, I'm happy to add it, since it solves some issues with cross-community content creation permission.
Is there a JSON-LD context I can add, since I am assuming that
postingRestrictedToModsis not standard? -
undefined nodebb@fosstodon.org shared this topic on
-
-
pfefferle@mastodon.social how has nobody complained about that yet? 😂
-
@julian 😘
-
Its part of the part of the Lemmy context so you could include that.
Btw I didnt notice your post before because Lemmy doesnt support mention notifications in that context yet (it will be in 1.0).
-
Its part of the part of the Lemmy context so you could include that.
Btw I didnt notice your post before because Lemmy doesnt support mention notifications in that context yet (it will be in 1.0).
Thanks! I will do just that... mostly since I don't feel like hosting my own context just for this one property.
This feature is now implemented and should ship with the next minor version of NodeBB — v4.8.0.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@evan thanks!
I would attend but unfortunately a winter storm hit and I'm at home watching three kids today 😑
-
@julian The ActivityPub API Task Force has a meeting today at 11AM EST. https://meet.jit.si/activitypub-api
-
@js@podcastindex.social thanks! 🤘
-
@julian hmm, I believe it tries to make each AP call from the browser first, then falls back to a cloudflare worker if that fails.
I just checked the cf worker and found this gem in it, so that might work for you too
-
I've seen hints of backfill working really well, but hadn't seen good examples until recently. As more and more instances upgrade to the newer versions of Mastodon that support context, backfill from Mastodon instances will improve across the board.
Today one of the most popular topics on my NodeBB instance was an update from the admin of The Forkiverse, a brand new up-and-coming instance. Despite following only one person from that instance, I was able to see every single reply from that instance, even from users I don't follow.
Super stoked to see resolvable contexts and backfill working in the wild. Who says the Fediverse is quiet? Not me, anymore 😅
-
Hi @silverpill@mitra.social right;
Move and Remove are explicit actions concerning membership of a context in an audience. Update is overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?) It is likely that sending audience as an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best Existing threadiverse apps check addresses, and audience may not be used at all in some.There is no conflict with Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.
-
Hm, it appears that none of my objections have been addressed.
Once again, why there are two activities Move and Remove, and not a simple Update or a new activity type?
-
Hey @js@podcastindex.social, I enabled Anubis for my site, but now requests from Browser.pub don't work :cry:
Is there something I can write a rule against, perhaps a header or user agent string that is unique to browser.pub?
