10 months ago
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
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.
10 months ago
@julian do it
also gee i sure wish people supported arbitrary rendering of any object/activity based on its name,/summary/content
also gee i sure wish people supported arbitrary rendering of any object/activity based on its name,/summary/content
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!
10 months ago
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.
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.
@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.
I think it's possible, but I need to think on it more.
@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.
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.
@scott@authorship.studio your post got me thinking about whether I was looking at it the wrong way.
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!
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!
@julian Most federated platforms treat direct messages like email. They are not instant, like chat. It is what some forum software calls "private messages."
So, in this case, the forums, private messages, inbox, and chat could all have different feature sets and permissions.
So, in this case, the forums, private messages, inbox, and chat could all have different feature sets and permissions.
10 months ago
To give an example of what I am talking about, here is how Hubzilla does it:
Inbox - Private / user can only see their own inbox.
- Incoming ActivityPub, Zot6, and Local Notifications
- Direct Messages / Private Messages (like email, but over ActivityPub)
Channels - Depends on permission for the channel.
- Social Media
- Forums / Discussion Groups
Chat - Depends on the permissions set and plugins installed.
- Real-time chat.
So, chat and direct messages are not the same thing, in this context.
Inbox - Private / user can only see their own inbox.
- Incoming ActivityPub, Zot6, and Local Notifications
- Direct Messages / Private Messages (like email, but over ActivityPub)
Channels - Depends on permission for the channel.
- Social Media
- Forums / Discussion Groups
Chat - Depends on the permissions set and plugins installed.
- Real-time chat.
So, chat and direct messages are not the same thing, in this context.