@[email protected] said in Article vs. Note vs. Page:

Since then WordPress has joined the Fediverse, and now Ghost is about to join as well. I think the ability to display rich content may soon become a serious competitive advantage.

Completely agreed. The best time to consider a different approach is now, so I am hoping we can make some headway here at the WG meeting. Stay tuned...

cc @[email protected] @[email protected]

Third party issues are subtle enough that they're obvious only after you actually have to deal with them. I've been dealing with them for a long time now. Both in private groups and multiple protocol interactions - where we were trying to make something from protocol 'A' visible to somebody using protocol 'B' when we ourselves used protocol 'C'.

Tokens are one way to do it, but they can be real tricky to secure, and they need to be stripped from conversational objects or inReplyTo's and de-duplication don't work correctly. Or give everybody in the conversation the exact same token - in which case they don't  really provide very good access control. These are things most people don't come to grips with until they try it.

We've traditionally implemented private groups in other protocols by doing a straight resend/relay of a signed activity by the group actor, and we did this in AP with LD-signatures for a while. I don't think Mastodon supports relaying any more because they're now verifying sender-id (via the HTTP-sig) against actor-id and rejecting mismatches.

FEP-8b32 along with Collections conveniently gets around all of the related issues. The sender and actor id of the Add activity matches, and the object is a complete signed activity.

@julian I am not sure but I guess so...

when I clicked the link on the first post of this topic: https://community.nodebb.org/topic/cd43b9f3-c032-44cc-adc8-f32e7ee91901/our-next-meeting/

it takes me here but gives error:

https://socialhub.activitypub.rocks/ap/object/1899f65c062200daec50a4c89ed76dc9

@devnull

infinite love ⴳ (@[email protected])

@[email protected] brevity

favicon

Mastodon (mastodon.social)

infinite love ⴳ (@[email protected])

@[email protected] more specifically, the examples use `audience` instead of to/cc, but you can use any of the three (to/cc/audience)

favicon

Mastodon (mastodon.social)

@julian Ooo good point about adding the ? back on.

If you're interested in a non-regex solution, here's what I have - https://codeberg.org/rimu/pyfedi/src/branch/main/app/utils.py#L247

This user story deals with expected behaviour when encountering a topic/context/first-order collection.

Perhaps it is discovered when declared as the context for an Object. The collection can then be used as the canonical source for content for that context, and it's members queued for asynchronous processing.

A scaling issue exists here in that a collection could be massive and cause an undue delay in processing a new Note if every other member of the collection needs to be processed first. Implementors should take care to not require the full context during processing of an Object.

As of today, the NodeBB-ActivityPub implementation now supplies both context and audience properties with every post.

N.B. When I say context and audience, these are also terms used by the ForumWG that refer to "topic" and "category", in NodeBB parlance.

Early indications from the last ForumWG meeting indicate movement towards the inclusion of context in a low-level as:Note object (a federated NodeBB post), resolvable as an as:Collection or as:OrderedCollection. The latter is what NodeBB will send, ordered by post time.

Discussions with @[email protected] also suggest that Discourse has the ability to parse an as:OrderedCollection context if provided, but currently does not if encountered as a property in a Note.

A minor change today also updates the audience property, which used to erroneously point to the context/topic, but now points to the audience/category. This change aligns usage of this property with FEP-1b12's expectations.

This change should allow other implementors to:

automatically group objects together given a the provided context, and more thoroughly backfill a given object's context, without relying on inReplyTo traversal

@julian

For example, let's say I link out to Evan's profile here. If NodeBB knew that this link had an alternative AP endpoint, then we could redirect the user instead to the local representation of his profile

Wouldn't Evan's AP endpoint be the same as his HTML endpoint?

Most platforms are going to send you to the authoritative profile, which is the one at the user's server.

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.

Maybe I am misunderstanding the use case here, but I am not sure why a platform would send you to a different platform to view the profile or channel.

@julian @rimu i think that was rimu actually, although i can probably give a summary

@[email protected] Yes, I think that's what @oplik0 and I ended up agreeing on. If we normalize all incoming requests so that any requests containing a full object on a different domain is just reduced down to its id, then you'd safeguard yourself from most edge cases. Applying FEP-8b32 would be handy to save yourself a few network calls but is optional.

The cost is you might have to make a couple extra calls, but it's probably worth it in order to keep the logic simple, predictable, and easily auditable.

@[email protected] hello! Unfortunately I'm busy this coming Tuesday but would be interested to chat about doing something in the future. Something I should be clear about first though is that I'm not involved in Podcamp Toronto or really in the podcasting community at all these days. I ended my last podcast around 2010, so most of my direct experience really is "historical" lol.

Ah it looks like this was covered by Angus' post over on SocialHub

@mutahar-ali You'd probably want to move the redis server to another machine in that case. Either a separate one, or on the same machine as the Mongo database.

@omega Right now in pages where there is a list of topics (e.g. /recent, /popular, etc.) there's a filter for "Uncategorized", which would essentially exclude everything else.

It's not as clear cut as excluding or only showing local topics, but that sort of achieves what you want. If you only want to see categorized topics, then you needn't select anything at all. By default, uncategorized topics are not shown.

What I think you're advocating for is a button to filter out ActivityPub topics even if they're categorized. That's where I think I might draw the line, because if a topic is categorized, then it is by that action it is considered (at least by the topic mover) to be related to the overall forum topic.

No in this feature we wish to post comments / message to user profiles. everyone can do that. for example wishing a user happy birthday on there profile.

@trwnh @julian @angus @nutomic groups can have subgroups

@[email protected] it was actually because of @ in actor IDs - the codepath for choosing a webfinger lookup over just accepting the URL as the ID only checked for its presence, and the code for webfinger lookups was only meant to run for the acct: protocol.

So yeah, not WP fault at all, just a combination of a bug and missing feature 🙂 Now both should be fixed.

Yeah, pretty much. angus: I think it would be helpful to work through an example of where this particular point of intersection may become an issue. Say you encounter an actor of type Group. You Follow the actor. You can't expect it to behave in any one particular way, but it will generally behave in one of these ways: It is a "normal" publishing actor. You will receive Create Object, Announce Object, Like Object, and so on. It is a boost bot. You will receive Announce Object for any object sent to it, mentioning it, etc. It is a 1b12 actor. You will receive Announce Activity, and other activities described in 1b12. It is a Smithereen-style actor. There will be a wall property, and it will send out Add activities where the target is that wall. The Add.object will also have a target, and this will match the Add.target as per 400e. Bonus: It is a context moderator. You will receive Add activities where the target is the object.context. It may also additionally be a "normal" publishing actor. So for any given "post", it might be a Create/Add/Announce/Announce-Create. This isn't limited to Group actors, but it is most prevalent in Group actors because of the popular (erroneous) interpretation of Group as equivalent to Facebook Groups. One final thing to note is that "normal" publishing actors and context moderators may be any type, not just Group -- there is no specific type dependency for these mechanisms, as they are the intended mechanisms. angus: So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that? Yup. id: type: Note attributedTo: context: content: "I'm posting in a thread" --- id: type: Note attributedTo: inReplyTo: context: content: "This post is in a different thread but still replying to the first" --- id: type: Article attributedTo: inReplyTo: name: "Some Article" summary: "In which I reply to a forum post with an entire blog post. This is not part of any context." content: "

Lorem ipsum dolor sit amet...

"

You're welcome. Please spread the word about NodeBB in your country. Thank you.

If I did things correctly, I should have a rudimentary two-way synchronization working now… I'm not sure if there's still a 5 minute delay between posting and federating... let's see.