System user for rejections

Wed, 02 Oct 2024 16:35:43 +0200 zuletzt bearbeitet: Thu, 03 Oct 2024 18:53:44 +0200

julian

julian@community.nodebb.org

So NodeBB does not support non-public activities yet, and that's problematic because there's actually no feedback to the sender (the activity is just dropped.)

I'm toying with the idea of a system user sending a rejection via a private note... and triggering everybody by calling the account MAILER-DAEMON

N.B. Actually there is a Reject activity sent, but of course, nobody actually accepts Reject heh.

mehr anzeigen 7 comments

Wed, 02 Oct 2024 17:00:35 +0200

infinite love ⴳ

trwnh@mastodon.social

@julian do it

also gee i sure wish people supported arbitrary rendering of any object/activity based on its name,/summary/content

Wed, 02 Oct 2024 17:02:10 +0200 zuletzt bearbeitet: Wed, 02 Oct 2024 17:37:14 +0200

𝓒𝓱𝓻𝓲𝓼

chris@im.allmendenetz.de

@julian
"non-public activities"

Did you have a look at "streams" ? There we find ways to deal with non-public activities - could this be adopted ?

Re: System user for rejections

Wed, 02 Oct 2024 17:02:48 +0200 zuletzt bearbeitet: Wed, 02 Oct 2024 17:03:11 +0200

julian

julian@community.nodebb.org

arbitrary rendering of any object/activity based on its name,/summary/content

@trwnh@mastodon.social yeah that was one of my ideas... to just let the user see privately the best-effort rendering of the object and then drop it after reading. At least then it would be seen!

Wed, 02 Oct 2024 18:10:24 +0200

Scott M. Stolz

scott@loves.tech

You might want to look at how Hubzilla (MIT), Streams (public domain), and Friendica (AGPL) implement non-public (private) activities.

I am not saying to implement it exactly the same way, but it would give you some clues since all of those have had non-public activities for awhile now.

If you want MIT licensed code, then Hubzilla would be best to look at. Specifically look at how they implemented private activities in the Zot6 protocol, and how they implemented private activities in the PubCrawl (ActivityPub) addon.

If you want bleeding edge code that is implementing that latest fediverse FEPs, then look at Streams and its Nomad protocol and also look at how he implemented private activities in ActivityPub. Keep in mind that some of his code, especially on the dev branch, is experimental.

And, then there is Friendica, which is AGPL. I am not sure how they implemented it, but they have addons for a number of protocols to view.

So there are a lot of working and production code that can be analyzed and reverse engineered.

Re: System user for rejections

Wed, 02 Oct 2024 18:13:13 +0200 zuletzt bearbeitet: Thu, 03 Oct 2024 18:53:43 +0200

julian

julian@community.nodebb.org

@scott@authorship.studio @chris@im.allmendenetz.de It's not actually the fedi side that I'm concerned about, it's simply that in NodeBB, at the post level, we don't have the concept of post visibility, so that makes the whole endeavour somewhat hard to reconcile with the existing codebase.

I think it's possible, but I need to think on it more.

Wed, 02 Oct 2024 18:21:21 +0200

Scott M. Stolz

scott@loves.tech

@julian Are you wanting to allow people to create private posts, or are you just wanting to be able to handle incoming private posts from other servers?

Because outgoing posts do not have to have the same features as incoming posts, and your forums, direct messages, and inbox can have different feature sets.

Re: System user for rejections

Thu, 03 Oct 2024 18:53:12 +0200 zuletzt bearbeitet: Thu, 03 Oct 2024 18:53:37 +0200

julian

julian@community.nodebb.org

@scott@authorship.studio your post got me thinking about whether I was looking at it the wrong way.

and your forums, direct messages, and inbox can have different feature sets.

Up until now I had completely written off integrating NodeBB's chat with ActivityPub. I figured chat was chat, and it'd be more suitable to integrate with a different protocol like Delta, and so I left it alone for some future undetermined date.

But while NodeBB posts themselves have no concept of visibility, our chat rooms do. @baris refactored the system so that users could come and go as they pleased, and their message visibility was indirectly tied to whether they were present in the room. The same system can be adapted for limited visibility messaging.

Back to the drawing board I go!