@[email protected] in that case if @[email protected] were to relax their restrictions on what context can contain to include both conversational contexts and reply trees, would that be sufficient?
Posts
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea) -
nodebb-plugin-reactions slow after selecting@phenomlab Can you share more details about what you mean? I attempted to open the Emoji dialog and browsed the site a bit. It seems to be responding ok.
Does it happen here?
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)If we're going to talk about favouring FEPs over minor technical aspects, need I remind you of the following from @[email protected]:
I continue to feel that this general idea is in keeping with the as-written intent of the context property. Adding a new property is likely to make adoption slower and more complicated. Adding a new object type is also likely to make adoption slower and more complicated, but less so than the property.
The more complicated you make something, the fewer implementors you're going to get. I haven't thought about these concepts nearly as long as you two have, but especially when you're talking about volunteer developers who have to work with other volunteer developers, any stumbling blocks could become insurmountable.
Simply put: there's a reason when someone wants to use OAuth2 SSO on NodeBB it's a free plugin, and when they want to hook into their corporate SAML SSO I charge a rather hefty sum.
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] @[email protected] I have the feeling we're getting too into the woods about defining what exactly a thread or context ought to contain and specifying that those definitions need to persist across all implementations.
I don't think they have to.
NodeBB considers a conversational context as a "topic"/"thread". ForumWG decided to refer to these as "contexts" for ease of discussion, but other software need not follow that paradigm.
If one implementor decided to utilise
context
to contain only one specific line of objects (a "sacredtimelinethread", if you will), I'd argue that's a perfectly valid use ofcontext
, and also fits into the definition of both of your FEPs. When they pull a NodeBBcontext
they'll get what NodeBB thinks is a context (the entire reply tree), and that's okay too.Basically, my argument is that yeah, as Evan said:
Anyway, I think we agree on more than we disagree on.
When we step back and think about what we want to achieve:
- Ability to reliably backfill a conversational context
- Declare a context owner that acts as a canonical source for context additions/removals (reply limiting and such)
Then what we're left with are three FEPs (7888, 171b, 763a) that all fit the bill but only differ in minor technical aspects.
-
Signalling "open in app" behaviour for AP content@[email protected] said in Signalling "open in app" behaviour for AP content:
And if you wanted to redirect a link to a local profile instead of his official profile, you don't need an endpoint to do that. You could simply parse the post and swap out the URL, since you should have data about the user in your database anyway from when you first detected the user.
Correct. In this scenario I don't want to be going to the authoritative profile, I would want to keep the user on-site.
If I had the user's
url
available, then yes, I can (and already do) swap out the URL. However, if somebody links out to some resource, I might not already know about that user, status, post, article, etc.In which case an opportunistic
HEAD
call would be one way to figure out pre-flight whether an AP object exists or not. -
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
i don't know of any forum software that chooses to present threads in reverse order with the newest posts at the top.
I'll bite. NodeBB lets you choose how to sort the posts. Chrono, reverse, or by vote count. Q&A forums might elect to use the latter two. But that's neither here nor there, it's a frontend UX thing and shouldn't really have any bearing on an AP S2S implementation detail.
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] @[email protected] I think end of the day it's an implementation detail that is of minimal significance. When I fetch the collection pages I don't trust the order anyway, I reorder them all by date once I have them all anyways.
@[email protected] said that reverse chrono for activities is preferable, and that makes sense if you want to sync up. Just retrieve activities until you reach one you've seen and you're caught up.
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
Do you have something like that in NodeBB? I wonder how others solve this "routing" problem
We do the same. We don't actually handle
Add
s right now, but ourUpdate
handler has aswitch..case
based ontype
.Adding a separate type would be easier, yes. Otherwise you're looking at additional logic to tease apart different variants that share the same base object type. For example, the logic for
Update(Note)
has further logic paths depending on whether the note is publicly addressed or not.So then yes, a
Add{target: Collectionish}
might be vague, but that's only the case if other implementations use the same. -
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
As a side note, it's beyond frustrating that the original goal of this topic was to accomplish reply-limiting controls.
I understand your frustrations, and for what it's worth, I feel like we need to get the more basic expectations out of the way first, that is: how do we meaningfully assign context to a set of individual posts, besides the already available but fragile
inReplyTo
traversal?At the same time, I do think that all four FEPs mentioned utilise the same mechanism for establishing basic reply-limiting... that there is a context owner that ultimately decides whether a reply is added to the collection or not.
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] Future discussions of the ForumWG may turn to more forum-like handling of context collections like forking, moving of posts, locking, pinning, etc.
In the former two cases,
inReplyTo
would no longer necessarily point to an object that is in the self-defined context collection. This is a very good point.@[email protected] also made this point recently as well.
-
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
It is for easier identification of conversation-Add activities. My server may receive many different kinds of Add activities, and it would be nice to have some indication of what collection is being modified.
In that case, are you trying to sidestep a potential future conflict? I think I can see your rationale that duck typing "resolved context is a Collection" may not be specific enough, but I am not currently aware of anybody outside of 400e/7888 that has a
context
that even resolves to anything. -
FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)Related to the ForumWG topic of resolvable context collections, there are four FEPs that are currently in consideration:
- FEP-7888: Demystifying the context property
- FEP-400e: Publicly-appendable ActivityPub collections
- Draft FEP-171b: Conversation Containers, an evolution of Conversation Containers
- FEP-76ea: Conversation Threads
@[email protected] made a suggestion last month to hopefully reduce the number of moving parts:
- Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)
- FEP-400e implementations: upgrade to Conversation Containers
- FEP-1b12 implementations: add target property to Announce activity that points to context collection.
This takes FEP 400e out of the running (potentially). But the day after that last meeting, @[email protected] put together FEP 76ea, and now we're back to three.
My concern is that all three FEPs (7888, 171b, and 76ea) all share these distinct qualities:
- They establish a conversational context for a given object
- They federate out an
Add
on collection addition. (76ea also sendsRemove
) - They contain some concept of a context owner (
attributedTo
)
They differ on the following qualities:
- 7888/171b use
context
whereas 76ea uses a new propertythr:thread
- 171b specifies a new object type
Context
- Collection items:
- 7888 sends objects in chronological order
- 171b sends activities in chronological order
- 76ea sends objects in reverse chronological order
In the lead up to the November WG meeting I'd like to address those differences. All three FEPs are in pre-draft or draft stages, and so I am hoping we can find some common ground and compromise.
Pinging interested parties (who were not already mentioned above) for comment:
@[email protected] @[email protected] @[email protected] @[email protected]
-
Using my sites subdirectory while runing Nodebb@eeeee the reason is because currently your reverse proxy setup is forwarding all requests to NodeBB, including that of
extras2
. So you will need to either adjust your proxy config to not do that for that folder, or update NodeBB to handle it. -
lot of memory consumption for nodebb@baris sass could be invoked on-demand when switching skins possibly.
-
I need a new language, and have the resources to translate it!@Christian-Stange you may start translating now, I've added the language.
When it has reached a state where you deem is ready, let me know here and I'll get it pulled in to NodeBB.
-
I need a new language, and have the resources to translate it!@Christian-Stange do you have a Transifex account? We'd ideally need a maintainer for the language. Let me know your account username please.
-
I would encourage every Fediverse software project to implement a “dead-man switch" on registrations: if nobody with moderator permissions has been active in the last week, then disable new account creation.@[email protected] most effective is by far just putting everything created by a new account behind a queue.
Sometimes you can't properly vet new accounts because the profile is empty.
The post queue stops everything we (NodeBB) receive from hitting fedi. Spammers have had ten years of practice against us. They simply can't get around a human review... mostly.
-
Did you know you can now follow https://socialhub.activitypub.rocks/ on Mastodon and (I hope) other #ActivityPub clients?@[email protected] a good question to ask is what Discourse (and also NodeBB) should do if multiple categories are mentioned at once just like you did.
If a category is mentioned then the post should appear in that category, no? But it can't (or maybe shouldn't, I should say) appear in all 5 categories at once haha.
NodeBB chooses the first out of the matches.
-
Federation issues on ekk.app@[email protected] @bh4-tech Glad to hear it is working now
-
Federation issues on ekk.appAttempting signed string verification
@bh4-tech that line above means that
ekk.app
is attempting to validate the HTTP signature sent bycommunity.nodebb.org
and is not coming up with the same result. The validation failure means the activity received cannot be trusted and is then dropped.Considering that NodeBB to NodeBB activities are tested as working, I'm inclined to think this is a configuration issue.
Can you please add the following line:
console.log(signed_string);
Right above this line in
src/activitypub/index.js
:// Verify the signature string via public key
... and attempt to send an activity to ekk.app again from here (or from https://activitypub.academy)?