@eeeee You may need to reach out to Zoho support to figure that one out... if NodeBB reports that the email was sent.
Could be you need proper DKIM and SPF records.
@eeeee You may need to reach out to Zoho support to figure that one out... if NodeBB reports that the email was sent.
Could be you need proper DKIM and SPF records.
@[email protected] Yes, that's certainly one use-case for the outbox... to "catch up" on things you missed, on a per-user basis.
But as far as I am concerned they're separate APIs that pull from a common data source.
For example, reading the ActivityPub spec, one could draw the conclusion that the outbox is an ordered list of activities, likely read as-is from the database.. but that's not strictly defined, so it's possible to dynamically create outbox items on-demand based on user history stored elsewhere.
That would mean less duplication of content (and the syncing that is required), fewer bugs, etc... but the cost is the collection then has to be dynamically constructed.
@[email protected] no legitimate reason, we just don't use it, and basic federation doesn't break when it's not implemented, so it's just very low down on our to-do list!
@Chris-Moser Thanks for sharing your implementation of context
in Yuforium!
That's definitely an interest use-case, although I am curious why you did not consider using the as:tag
property instead, given that it seems to be a rough parallel to your Topics.
In that scenario, then you could limit context
to what you would call Communities, though depending on how it is used, maybe audience
could be a better fit (as per FEP-1b12)
@[email protected] personally, I'm still waiting for someone to call me out on having actors whose outboxes resolve to an empty collection
ducks
I have created a spreadsheet with open editing permissions (for now) and invite implementors to add their implementations if applicable.
One thing I am noticing now (and should've expected) is that not every software has the concept of a discrete context, nor can you expect one from remote activities. In those scenarios, the fallback seems to be to point to the root-node Object and iterate via replies
collection.
For example:
context
as the root-node Object.context
is received, inherits it, but otherwise, context
becomes the root-node Object.@[email protected] does FEP-7888 account for this use-case?
@[email protected] said:
Letterbook will. I'm flexible as to how, but my current plan is to duplicate the OP's replies collection into the context.
Good to know, I'll add your potential implementation into the table I'm creating... at present I'd want to know the current or potential usages of context
. Hopefully there won't be too many disparate and incompatible implementations to reckon with...
@[email protected] Thanks for sharing this use-case, it's very helpful and quite novel, I might add!
An inReplyTo
array addresses the problem of backfill/ghost-replies with a bottom-up approach, vs a context collection which would be a top-down approach... though depending on what direction your tree grows, perhaps it's the other way around
A context collection would also provides the entire tree, which depending on size may or may not be preferred. Tradeoffs...
I think perhaps there is space for both, although I will admit that if my code encountered an Array in inReplyTo
it might just terminate because it expects a single uri.
re: the original ask, specifically I was asking whether any other implementors specify context
in an as:Note
, resolvable to a Collection.
Could you provide an example of such post?
I believe @[email protected] was referring to the fact that the software itself supports inline images locally. Well, sure, who doesn't? (Except for Mastodon lol)
The problem lies with everybody federating as:Note
out because Mastodon doesn't render content
otherwise, and also that all images are stripped out unless included as attachment
, and only then, in reverse order with a cap at 4 images.
@[email protected] said in Part of my frustration with #ActivityPub and one of the things I find baffling giving everything else in it: the lack of tools for backpressure.:
And of course as mentioned we use them for conversations so that everybody sees the same view of the discussion. It's a very under-utilised organisational mechanism and that seems odd. They're quite useful.
Ah yes, that was what I was referring to, a collection for a conversation. It certainly does seem under-utilised but I wasn't entirely sure whether that was true or not.
Are you aware of any other implementors that expose a collection for a collection of a topic's content?
@[email protected] do you know any other implementors who expose a collection (even if not defined by context
)?
@[email protected] @[email protected] I'd recommend we discuss the merits and complexities of media caching separately, if only because I'm certain we could bikeshed that one for days!
@[email protected] @[email protected] if the collection contains the entire activity log pertaining to the context, then it makes it harder to determine whether a given object is contained in the collection (as @[email protected] mentioned in another thread). If you see a Create(Note)
you can't be certain it doesn't get Delete(Note)
'd later on in the collection!
@bdinfl you put the ratings in your template with <!-- IMPORT partials/ratings.tpl -->
It can go on the topic list or inside a topic.
@[email protected] even that has it's own exceptions. This very topic's OP was meant to be a reply to the original Article vs. Note vs. Page topic, but I decided to make it a standalone topic for tagging purposes.
That's why I still feel that we can use simpler heuristics based on content to determine whether one ought to use Article or Note...
But a part of me worries that we're heading down this road trying to figure out whether we can heuristically determine an object type, when we should be asking whether we should.
@[email protected] oh! Now I can put a face to a name!
Yes... I myself also have a "spiel" I send when I do these sorts of engagements. That's why I noticed when there wasn't one!
At the last ForumWG meeting, we discussed at length about Article vs. Note, and whether there was a desire to expand usage of as:Article
. You can review those minutes here.
One of the action items that came out was to collate the state of current implementations. Unfortunately, outside of implementations that federate non-textual content (e.g. Pixelfed Stories, Mobilizon Events, etc.), the majority of implementors just use as:Note
, which is not surprising given Mastodon's treatment of non-Note objects.
You can see the results of the summary here.
What is less clear is whether there is pent-up demand for use of a different data type for more richly forrmatted content. @[email protected] and @[email protected] provided some very illuminating history behind previous attempts to use as:Article
, but importantly it seems that Mastodon (via @[email protected]) may be open to supporting this in some form as well.
While Mastodon has every reason to display as:Note
as it sees fit, I'd like to hopefully address the undue influence towards using it especially in instances where as:Article
were more appropriate. Mike (upthread) suggested a compromise:
as:Note
be reserved for content with attachments (images or otherwise), perhaps with a limited subset of htmlas:Article
be used for content with a richer set of html (e.g. tables), and including the ability to display inline imagesI explicitly did not specify that Note was for shorter content and Article for longer, because there exist plenty of examples of the reverse.
Does anybody see potential complications from such an arrangement?
My post from a couple weeks back indicated that NodeBB started following part of FEP-7888: Demystifying the context property.
Our implementation is an endorsement of @[email protected]'s proposal that the context
property be given additional formalization.
During the last ForumWG call, they intentionally (or perhaps unintentionally) summarized their desire that implementors should "just use collections", and that that would be a good starting point for future iteration.
With the current state of context
being "there is no coordinated usage of context
", this topic aims to provide a snapshot of implementors' use of that property (or lack thereof), and to stimulate further discussion on potential use cases.
Note that this is not the first time the question has been raised. trwnh's discussion topic contained one such summary of current implementations.
As per that topic:
context
, but provides an ostatus:conversation
propertycontext
, but the url provided is unresolvable, likely used similarly to Mastodoncontext
, resolves to an OrderedCollection
containing all activities encontered (Creates, Updates, etc.)My hope is that a provided context
resolving to a Collection (or subtype thereof) would allow for proactive topic backfill, instead of relying on reply chain traversal, which while workable, has some rather specific downsides.
As mentioned per the above linked announcement that NodeBB was following FEP-7888:
context
to all Note
objects (NodeBB posts), and it resolves to an OrderedCollection
that contains the uris to the other objects in the context (the NodeBB topic).@Julien-Heng Let us know any errors on the front-end or backend.
Make sure a composer (like composer-default
) plugin is active in the backend.