@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.
Those who prefer GNU/Linux over any other OS.
@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.
@NodeHam Sorry for late response. Can you provide a bit more detail as to what you want to achieve? For example, would the iframe
component be the same for each user, or would each user have something different?
One cheap way to accommodate this would be via NodeBB's hooks, and a custom jQuery function in lieu of a plugin.