Adding/removing "pinned statuses" to an actor
Technical Discussion
1
Posts
1
Posters
17
Views
-
Mastodon has a concept called "pinned statuses", which is a special collection attached to a Person actor.
https://docs.joinmastodon.org/spec/activitypub/#featured
It wasn't readily known how this collection is updated and federated (not without code achaeology), but claire@social.sitedethib.com recently shared some additional info :smiley:
- The actor itself will issue an
Addactivity targeting the collection with the status inobject. - This activity is sent to all followers of the actor.
- No activity is sent if the actor has no remote followers.
- A
Removeis sent when a pinned post is unpinned.
This is what the
Addlooks like:{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Add", "actor": "https://example.org/users/testUser", "target": "https://example.org/users/testUser/collections/featured", "object": "https://example.org/users/testUser/statuses/115266412340579560" }The corresponding
Removeis identical except fortype, which is of course,Remove. - The actor itself will issue an
Gli ultimi otto messaggi ricevuti dalla Federazione
-
I've seen hints of backfill working really well, but hadn't seen good examples until recently. As more and more instances upgrade to the newer versions of Mastodon that support context, backfill from Mastodon instances will improve across the board.
Today one of the most popular topics on my NodeBB instance was an update from the admin of The Forkiverse, a brand new up-and-coming instance. Despite following only one person from that instance, I was able to see every single reply from that instance, even from users I don't follow.
Super stoked to see resolvable contexts and backfill working in the wild. Who says the Fediverse is quiet? Not me, anymore 😅
-
Hi @silverpill@mitra.social right;
Move and Remove are explicit actions concerning membership of a context in an audience. Update is overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?) It is likely that sending audience as an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best Existing threadiverse apps check addresses, and audience may not be used at all in some.There is no conflict with Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.
-
Hm, it appears that none of my objections have been addressed.
Once again, why there are two activities Move and Remove, and not a simple Update or a new activity type?
-
Hey @js@podcastindex.social, I enabled Anubis for my site, but now requests from Browser.pub don't work :cry:
Is there something I can write a rule against, perhaps a header or user agent string that is unique to browser.pub?
-
@thisismissem said in ActivityPub API Client Reputation:
> Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation.I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc.
> You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration.
Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost!
I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients.
> That's why we wrote the CIMD spec.
Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers.
> But OAuth security and trust models are complex and generally proprietary
I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be:
How many people on this server (or other servers) have authorized the client What the average rating has been (but you need a way to rate clients!) How many Flag activities have been submitted for this client (you need a way to report clients) Reviews of the client (you need a way to write a review of a client)That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
-
@bentigorlich@gehirneimer.de in the relevant issue in Mbin's issue tracker raises a wording concern: "resolvable context" is an unfamiliar term to those who have not read through FEP 7888.
I will update the FEP to make this definition more explicit.
https://github.com/MbinOrg/mbin/issues/248#issuecomment-3741019183
-
Tagging relevant parties:
@rimu@piefed.social of Piefed @nutomic@lemmy.ml of Lemmy @bentigorlich@gehirneimer.de and @melroy@kbin.melroy.org of Mbin
-
The submission of the FEP and timing of this post are intentional as there are now two implementors supporting (part of) this FEP.
NodeBB as of v4.7.0 Piefed as of v1.5As the implementors work through any issues, the FEP and this topic will be updated to reflect those changes.
