Pre-Alpha ActivityPub-related bug reports
-
@julian I'm maybe not seeing the right post, but on the "duplicate content" issue, if you've an unauthenticated user viewing a federated post or account, the best practice is to provide an intersitual saying “This post wasn't made it, click to view the original post”
This is what it looks like in 4.3 for mastodon: https://github.com/mastodon/mastodon/pull/27792
-
@julian Why? because the unauthenticated user should not be able to view federated content, since this may make you susceptible to public cache poisoning attacks, where a third-party could make you publicly display CSAM content, and then it looks like you're displaying it first-party and hosting CSAM to your hosting company, who takes your server down immediately and/or reports to LEO.
We've already seen this attack used to take down fediverse servers.
-
@julian
I often feel like I am pushing against the "ActivityPub zeitgeist" of sorts, because I am plainly advocating for a thoughtfully designed pull-based mechanism for backfill purposes, but at least among those I've talked to, I'm not hearing any pushback.
Hubzilla and Friendica were one of the first platforms to implement forums (or more accurately "discussion groups" although the only difference is the UI). The biggest challenge at the time was that other platforms didn't (and most still don't) understand groups and group discussions.
When developing, they basically used the following tactics:
1. Implement full discussion group features within Hubzilla, and Friendica, respectively. People who use those platforms get the full experience and full feature set.
2. For platforms that don't have the same features, they implemented what they could. If other platforms don't support certain things, that is not our fault. But we still designed it so that it works with their platforms, mostly using workarounds. They could at least participate, even if they didn't get the full experience.
I think we need to take the same approach. We design it so that thread-based platforms (forums, discussion groups, Facebook-style social media, etc.) all can interact with a full set of features. For social media platforms that don't support threaded conversations, we just do "best effort" accepting the fact that their users will have a degraded experience because their software doesn't support the same features.
So, I would recommend that we create some method of backfilling a thread from the authoritative source (using a pull mechanism), and we advertise that this functionality is available via webfinger and as part of the meta data of the posts themselves. Platforms that don't know what that is will ignore it. Platforms that know what that is will use it.
ActivityPub seems to be a push only protocol, so we may need to make our own mini-pull protocol for this purpose. You can look at the Zot protocol that is part of Hubzilla as an example. I think the Nomad protocol that is part of Streams also does the same thing. Not sure about Friendica. But there is working code that already pulls the entire thread. -
@Emelia
@julian
I don't think there really will be a duplicate content issue. Typically, copies of posts are delivered to people's private inbox, not reposted publicly on other websites. Unless someone is operating a relay or reposting other people's posts, all of the copies of the post that are sent over ActivityPub should be private. -
Scott M. Stolzreplied to crazycells on last edited by@crazycells Search engines would not see them. ActivityPub basically serves as a notification mechanism, except it delivers the entire post to the follower's private inbox and they can reply back without visiting the forum. Forum posts and comments do not get republished publicly.
-
Steve Batereplied to Scott M. Stolz on last edited byscott:
Search engines would not see them.
This doesn't seem to be true.
The content of Julian's post at https://socialhub.activitypub.rocks/t/hi-julian-i-wonder-how-search-engines-and-seo-will/4135/12?u=stevebate is indexed with both socialhub and nodebb URLs.
Google SERP screenshot:
-
I received an activity with this ID:
https://community.nodebb.org/post/100125#activity/create/1719328808532#activity/announce/1719328833687It has two #-signs. I think it is not a valid URI: https://datatracker.ietf.org/doc/html/rfc3986#section-3.5
A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.
-
@[email protected] I see it, thanks for reporting, just pushed a fix, let me know if the IDs still look funky.
-
@the-skyfoxx can confirm this behavior.
/cc @julian any fix comming (soon)?
-
-
@julian said in Pre-Alpha ActivityPub-related bug reports:
@macfan hi, to which issue were you referring to?
I think this one: https://community.nodebb.org/topic/17867/pre-alpha-activitypub-related-bug-reports/13?_=1719346171531
But seems to work for me now
-
T the skyfoxx referenced this topic on
-
This post is deleted!
-
@julian The URL of this topic is https://community.nodebb.org/topic/17867/pre-alpha-activitypub-related-bug-reports
When I make a request with AP Accept header, the server responds with aCollection. Technically, this is not wrong, but I think most people would expect a top-level post (Note / Article) when making such request -
@[email protected] you're the first person to have noticed!
It's by design, but of course, can — and maybe should — change. It's part of @[email protected]'s FEP-7888 and its concept of a resolvable collection.
Mapping the topic URL to the top post (or perhaps a redirect to it) would ensure compatibility with Mastodon, but I am unsure of whether that is the best path forward.
-
@julian @silverpill why would anyone expect a Note/Article when fetching the URL for an entire thread/topic?
-
Emelia 👸🏻replied to infinite love ⴳ on last edited by
@trwnh @julian @silverpill I'd only expect a Note/Article when explicitly requesting the first post in a thread/topic, not when fetching the topic itself
-
@[email protected] @[email protected] that was my thought as well, and why NodeBB currently responds as it does.
Ideally it could be both an Article and a Collection, but now we're really committing to incompatibility there lol
-
@julian @trwnh @silverpill I mean... theoretically ActivityPub allows for multi-typed objects due to json-ld
But will anyone understand that correctly? No idea.
-
infinite love ⴳreplied to Emelia 👸🏻 on last edited by
@thisismissem @julian @silverpill you could generate a document that is both an Article and a Collection but i'm gonna go out on a limb and say that this is probably *not* what you want. it's a thread. a thread is a Collection of posts. it's already "ideal" to represent it as a Collection and not an Article.
i suspect the source of confusion is that most other projects don't have threads/topics, they have reply trees which they show below the "top level" post. The URL there is for the post.
-
silverpillreplied to infinite love ⴳ on last edited by
@trwnh @julian Because it is not clear how client should display this collection. Searching for URL is a common UI pattern: user expects to see a post or a profile as a result (this is not unique to Mastodon).
Server can attempt to fetch the first item in a collection, but NodeBB's FEP-7888 collection doesn't identify itself as a "thread". It has "OrderedCollectionPage" type and properties that many other collections also have
