What are the activity_id formats for various platforms?
Fediverse
12
Posts
5
Posters
84
Views
-
TL;DR: Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I've rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I'm loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that's submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/for users/c/for communities/post/for posts/comment/for comments.
For Mbin, I think it's the same except it uses
/m/for communities (they call them "magazines" I believe).I think mastoon uses
/useror maybe/username/in the AP identifiers?Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
-
TL;DR: Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I've rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I'm loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that's submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/for users/c/for communities/post/for posts/comment/for comments.
For Mbin, I think it's the same except it uses
/m/for communities (they call them "magazines" I believe).I think mastoon uses
/useror maybe/username/in the AP identifiers?Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
From my own experience querying public mastodon timelines via API (edit: removed incorrect
/api/v1s in the AP_IDs):- Mastodon user accounts have an ActivityPub URI of
https://<instance.domain.tld>/users/<username> - Mastodon posts have an ActivityPub URI of
https://<instance.domain.tld>/users/<post_author_username>/statuses/<post_id>(they also have aurlproperty ofhttps://<instance.domain.tld>/@<post_author_username>/<post_id>but that tends to serve the html view of the post)
To see for yourself, pick an instance that allows viewing their public timeline without logging in (
mastodon.socialis perfect for this) and follow the "Playing with public data" section of the docs. That page ellides most of the info you're looking for in the example payloads they give (as the JSON payloads themself are quite large and nested), but I can assure you that AP_IDs for user accounts and posts can be found pretty quickly from a single timeline query.I don't think Mastodon has any notion of community, nor does it distinguish between posts and comments (when following a lemmy community, both posts and comments show up in my masto feed as "top-level" statuses (ie posts)).
-
TL;DR: Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I've rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I'm loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that's submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/for users/c/for communities/post/for posts/comment/for comments.
For Mbin, I think it's the same except it uses
/m/for communities (they call them "magazines" I believe).I think mastoon uses
/useror maybe/username/in the AP identifiers?Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I’ve rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I’m loving this as it makes things so much faster and easier.
Isn't that the whole point of webfinger? Moreover, why would you paint yourself into a corner and hardcode the logic for all the different types of services, if ActivityPub uses JSON-LD and therefore provides a straightforward method for document dereferencing?
I'm not trying to be snarky. It's just that I'm writing ActivityPub server where the id of each object is just an ULID, because to the server there is zero difference between serving the information about an actor or an activity.
-
From my own experience querying public mastodon timelines via API (edit: removed incorrect
/api/v1s in the AP_IDs):- Mastodon user accounts have an ActivityPub URI of
https://<instance.domain.tld>/users/<username> - Mastodon posts have an ActivityPub URI of
https://<instance.domain.tld>/users/<post_author_username>/statuses/<post_id>(they also have aurlproperty ofhttps://<instance.domain.tld>/@<post_author_username>/<post_id>but that tends to serve the html view of the post)
To see for yourself, pick an instance that allows viewing their public timeline without logging in (
mastodon.socialis perfect for this) and follow the "Playing with public data" section of the docs. That page ellides most of the info you're looking for in the example payloads they give (as the JSON payloads themself are quite large and nested), but I can assure you that AP_IDs for user accounts and posts can be found pretty quickly from a single timeline query.I don't think Mastodon has any notion of community, nor does it distinguish between posts and comments (when following a lemmy community, both posts and comments show up in my masto feed as "top-level" statuses (ie posts)).
Cool, thanks. I was close with
/userguessing from memory.I think the
/users/.../post_idwill be sufficient. It just needs to know that the given URL is an AP_ID before passing it off to the API call toresolveObject. Since it already knowsinstance.domain.tldis a federated instance, it just needs to see if the path is an AP_ID or the HTML (or something else). Thus, I don't have to parse the whole thing, just check that enough of it matches.Thanks!
- Mastodon user accounts have an ActivityPub URI of
-
So, I’ve rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I’m loving this as it makes things so much faster and easier.
Isn't that the whole point of webfinger? Moreover, why would you paint yourself into a corner and hardcode the logic for all the different types of services, if ActivityPub uses JSON-LD and therefore provides a straightforward method for document dereferencing?
I'm not trying to be snarky. It's just that I'm writing ActivityPub server where the id of each object is just an ULID, because to the server there is zero difference between serving the information about an actor or an activity.
We've had this discussion :)
This application is written against the Lemmy API. It only speaks API. Eventually it'll speak Piefed API as well, but right now, only Lemmy API.
Lemmy and Piefed only do server-to-server Activity Pub and not client-to-server AP. Clients have to use the API to interact with them. This is a Lemmy (and eventually Piefed) client.
-
We've had this discussion :)
This application is written against the Lemmy API. It only speaks API. Eventually it'll speak Piefed API as well, but right now, only Lemmy API.
Lemmy and Piefed only do server-to-server Activity Pub and not client-to-server AP. Clients have to use the API to interact with them. This is a Lemmy (and eventually Piefed) client.
But then why do you worry about the ap_id patterns from other software?
-
TL;DR: Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I've rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I'm loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that's submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/for users/c/for communities/post/for posts/comment/for comments.
For Mbin, I think it's the same except it uses
/m/for communities (they call them "magazines" I believe).I think mastoon uses
/useror maybe/username/in the AP identifiers?Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
admiralpatrick@lemmy.world I think you would be better served by checking for the Link header. NodeBB and WordPress do it, if that gives you some idea of implementation?
-
It took me a minute to find, but it is detailed in evan@cosocial.ca's write up about HTTP Discovery of ActivityPub Objects.
This is probably exactly what you're looking for.
https://swicg.github.io/activitypub-html-discovery/
I think your current approach has merit but is limited. If you know the instance software by URL and can resolve it using path matching without the use of a pre-flight request, that's absolutely a better way forward. The downside is you have to know the URL patterns of every software. You'll never "catch 'em all"!
However, if that method fails, doing a pre-flight check to grab Link also works and is a viable way forward.
You can test against NodeBB users or posts.
-
But then why do you worry about the ap_id patterns from other software?
I'm making an "omnisearch" box.
Paste in an AP_ID into the search field, and it auto-resolves it and redirects you to your instance's local copy (which is very fast) instead of going through the whole search process (which is slow). To prevent false positives, I'm matching the various ap_id formats and only doing the resolution on those; anything else gets passed to search.
Anything else that falls through the cracks just gets passed to search as usual (which also does a resolveObject lookup).
It's to make life easier.
-
I think you would be better served by checking for the Link header
Can't really do that, client-side, in a browser application. CORS is a perpetual cockblock (though I understand why it is), and I'd rather not make an internal API endpoint to do the lookup.
The application polls Lemmy's
getFederatedInstancesAPI endpoint at startup, so it has a list of every activity pub server your instance knows about. That's the first and primary check for the URL that's being searched.The second check is just to rule out non activity pub URLs that point to a federated instance (e..g. https://lemmy.world/modlog, https://lemm.world/pictrs/image/blah.webp, etc).
Goal isn't to "catch 'em all" but to catch the most used ones. If there's one I don't account for, either by omission or because the federated platform didn't exist when I made the patterns, then it will just fall back to a regular search which also includes trying to resolve it as a federated URL (which is the current behavior in all prior versions).
The goal is just to simply short-circuit the search behavior if the query is a known ap_id URL in order to avoid a lengthy search process and quickly redirect you to your instance's local copy.
-
TL;DR: Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
So, I've rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I'm loving this as it makes things so much faster and easier.
To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that's submitted to the search.
Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search.
For Lemmy and Piefed, those are:
/u/for users/c/for communities/post/for posts/comment/for comments.
For Mbin, I think it's the same except it uses
/m/for communities (they call them "magazines" I believe).I think mastoon uses
/useror maybe/username/in the AP identifiers?Any of you who are more familiar with Fediverse platforms that aren't Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
I maintain my own Lemmy client (Blorp), and this sounds like a cool idea. How do you get your known list of federated instances?
I currently have my own threadiverse crawler I wrote, but I disregard any Lemmy/PieFed instance with <20 monthly active users. That brings the list down to about 63 Lemmy instances and 7 PieFed. I wonder if that list is extensive enough to implement the resolve object mechanism you mentioned.
-
I think you would be better served by checking for the Link header
Can't really do that, client-side, in a browser application. CORS is a perpetual cockblock (though I understand why it is), and I'd rather not make an internal API endpoint to do the lookup.
The application polls Lemmy's
getFederatedInstancesAPI endpoint at startup, so it has a list of every activity pub server your instance knows about. That's the first and primary check for the URL that's being searched.The second check is just to rule out non activity pub URLs that point to a federated instance (e..g. https://lemmy.world/modlog, https://lemm.world/pictrs/image/blah.webp, etc).
Goal isn't to "catch 'em all" but to catch the most used ones. If there's one I don't account for, either by omission or because the federated platform didn't exist when I made the patterns, then it will just fall back to a regular search which also includes trying to resolve it as a federated URL (which is the current behavior in all prior versions).
The goal is just to simply short-circuit the search behavior if the query is a known ap_id URL in order to avoid a lengthy search process and quickly redirect you to your instance's local copy.
Can you not call fetch() to do a HEAD call? Maybe I'm mistaken about it but it should be ok.
CORS is indeed a wrench that gets thrown in when you least expect it...
Gli ultimi otto messaggi ricevuti dalla Federazione
-
so, this is a bit of an abstract mathematical post.
I think that a fediverse service consists mostly of three parts: identity provider, data hoster, and feed provider.
The data hoster is the machine that hosts the posts and comments and upvote/downvote stats. The feed provider is the service which gives you a nice, scrollable overview over new content for you. This is today the same system that provides the data, but it could be separated, such as having a custom "search engine" that gives you content, that you use independently of where the data is stored.
The identity provider basically only makes a proof that "you are you" : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i'm on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.
What i argue now is that such an identity providing server is not technically necessary. You could use something like an ~/.ssh/id_rsa file that you generate on your own computer and use that public key to identify yourself on the fediverse. I don't think that this approach has any inherent advantages over how things are being done today, but it could be done that way and that in itself is fascinating.
:D
-
It looks like some issues may arise if/when an instance's domain name changes. Is there any way we can change federation so that we don't need to rely on such a central point of failure?
-
@hendrik@palaver.p3x.de fwiw NodeBB ended up being such a joy to author things in that we switched away from WordPress to NodeBB as our blog. We just blog on our forum.
Now, conflicts of interest are important... I wrote NodeBB, so I am obviously pretty biased :laughing: !
-
Unless you are on a frantic hurry to make this change, I might be able to help. You'll need to migrate to Wagtail, and I have done some work on integration with Wagtail and the Fediverse via the Django ActivityPub Toolkit. But if you do consider this, you'd have to keep in mind that the ActivityPub side of things would be a ongoing experiment.
-
No matter what plugin you find that supposedly will do the job, in my experience it is always a PITA that ends up involving a lot of programming.
I had a good experience with jekyll's wordpress->jekyll import tool. But see below.
I would go for a database-less static site generator like Hugo
Graybeard here, so it's probably just braindamage specific to me, but I've found ruby dependency setup and troubleshooting to be extremely frustrating. Hard for me to wrap my head around.
When jekyll is actually dead (right now it is "only mostly dead") I'll change to something that does not require ruby (eleventy?) or just go back to the nineties and do something barebones with gtml or whatever. Already playing with the latter.
-
Yes. I'm not very educated on the Worpress side of things... Kinda necessary, though, to keep compatibility with the Fediverse AND the No-AI people in my opinion. I mean the Fediverse is kind of the place for people to go if they don't want algorithms and bots to dominate the place?!
-
Our first priority will be to migrate the site as fluently as possible to whatever CMS we transition to. Archiving it as HTML and starting from scratch with a new platform — that's a last ditch effort, I think.
[Edit: I tried to cover the WP fork subject here]
Hugo as a longterm solution isn't going to float with some of our users, I'm afraid. I can vividly imagine somebody turning the old site into a single "Hello world!" page given that kind of permissions.
We will need strictly limited access for contributors, and a clear, friendly input field for text...
-
maybe go for a combination of them
This is a very practical solution... until somebody (I suspect me) has to maintain three or more installs instead of one 🙂 But you're right, this could very well be a way to solve the "one size fits none" conundrum.
As for using a WP fork — the point about the ActivityPub plugin breaking compatibility with ClassicPress makes me wary of this approach. And AFAICT ClassicPress is one of the more reliable WP forks out there? In the long term, I mean.
I'm fine with switching my personal browsers if/when one or the other FF fork turns to the dark side, but I wouldn't want to hop this site between different WP forks the same way...
