People are Starter Packs
Technical Discussion
3
Posts
2
Posters
21
Views
-
I think that my comment on GitHub that Group Actors acting as Starter Packs really comes from how I approach my social network.
I rely on my friends and peers to discover new topics and meet new people.
Friends and peers as Starter Packs work great on a small microblog instance like Mastodon, Misskey, or Sharkey because the federated feed/bubble lists topics written by the amazing people that they are following. This approach is ideal for small instances, but flagship, large and relayed instances make it much harder as the topics are much too diverse.
When a small instance I was part of shutdown, I was really at a loss because I relied heavily on that feature without following people myself i.e. I'm lazy. And so to figure out who to follow, I went back to my peers’ and friends’ following Collection. Note to self, I need to remember to continually discover more people from people I follow now that I am on my own single-actor instance.
This is why I come to the conclusion that people are Starter Packs. Or in other words, Actors are Starter Packs. And more specifically, anyone or thing with a publicly-available following Collection is a Starter Pack.
But making a public directory of everyone is not a good idea and discoverability is hard.
Starter Packs should be (Group) Actors because
- Consent is built-in with the Follow Accept/Reject.
- People that want to explicitly allow followers already have this option.
- Implementations should use Mastodon’s
discoverabilityproperty to also limit who a Starter Pack may follow.
- Revoking consent is mostly built-in with either Remove Follow, Block Undo, or Reject Follow.
- Discoverability is built-in:
- The following Collection is available.
- Group Actors can make posts when their following Collection is updated.
- Amazing UX designers can make the following Collection more usable in their software.
- Starter Packs that are used in bad faith can be defederated like any other bad faith Actor or instance.
- The barrier to implementation is much lower than tacking on anything new to the specification.
- Consent is built-in with the Follow Accept/Reject.
-
mradcliffe@nokoto.org apart from the technical details, this approach also is extremely easy to explain to laypeople.
"Follow who this person follows" :heavy_check_mark:
-
Thank you, @julian.
One thing I am concerned about is how that affects forums and communities.
But then I think, so what if a NodeBB forum or PieFed community wanted to highlight people because those people represented the values of that community (even if they were not necessarily a part of it)?
This is something that no forum software that I am aware of does because we always think of forums as only something we join into.
And it is so amazing to me that the FediVerse and the social web movement could provide a forum or group the opportunity to grow in the opposite direction—sending people outwards for new shared experiences.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
#askfedi #peertube #makertube #spectravideo #activitypub #fediverse
I've recently been trying to remote follow some accounts from my own peertube instance from https://makertube.net and https://spectra.video and at first it seems as though it's successful, but shortly after the subscription disappears.
Is anyone else having this issue?
-
@evan said in ActivityPub API Client Reputation:
> @thisismissem said in ActivityPub API Client Reputation:
>
> > I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
>
> Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way.One could hope, but they weren't willing to back the huge amount of work to deprecate non-expiring access tokens, so that'll probably be exploited first, since there's quite literally millions of non-revoked access tokens out there.
I tried to do the work to fix it on my own, but it's literally months of work to implement correctly with enough test coverage. Without them either paying me or promoting/acknowledging my work, I ran out of my own budget to be able fix their problems.
> > You can't Flag a non-activitypub JSON document.
>
> I think you can, if you use the Link type.
>
> json > { > "@context": "https://www.w3.org/ns/activitystreams", > "type": "Flag", > "id": "https://social.example/activity/flag/1", > "actor": "https://social.example/user/3", > "object": { > "type": "Link", > "mediaType": "application/json", > "href": "https://client.dev/oauth/metadata.json" > }, > "content": "This is an example Flag activity for a CIMD document." > } >That'll flag it at this point in time, and the contents can change. And software in the fediverse is unlikely to be able to understand receiving a flag like that.
> At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever.
Yeah, requires folks to actually build moderation tools for that and ensure moderating against an application revokes its access completely. Revoking access tokens doesn't prevent usage of data already harvested or whatever, but does prevent ongoing abuse
-
@thisismissem said in ActivityPub API Client Reputation:
> I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way.
> You can't Flag a non-activitypub JSON document.
I think you can, if you use the Link type.
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Flag", "id": "https://social.example/activity/flag/1", "actor": "https://social.example/user/3", "object": { "type": "Link", "mediaType": "application/json", "href": "https://client.dev/oauth/metadata.json" }, "content": "This is an example Flag activity for a CIMD document." }A reputation system doesn't have to be perfect to be useful. And it's much more important to collect and share negative signals than positive ones.
I understand that you don't trust app store reviews or ratings but literally billions of other people do. When I go to download an app and it's got a 2.8/5 score, it gives me pause, and I read the reviews to see what the problem is. Sometimes I'll google the app by name. I am unlikely to install it, unless it's really the only software out there that does what I need it to do.
At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever.
I think I understand the use of the content hash, thanks!
-
@evan said in ActivityPub API Client Reputation:
> the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal.I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
> > 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.You cannot rely on the contents of a CIMD not changing though, for that you'd need to calculate like the CBOR CID of the JSON (that's what I do in https://cimd-service.fly.dev)
> > 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:You'd be surprised, but no. Whilst I was on the hachyderm infra team, I ran a tonne of queries for research on the data they have for registered OAuth clients, and there's really not a lot of great insight, besides "this app was added a lot to accounts", which isn't really a good score of trust (see: Cambridge Analytica).
> - How many people on this server (or other servers) have authorized the client
Meaning number, overall. The top registered client on Hachyderm was actually a dead research project if memory serves (found that out after reaching out to the author, and promptly revoked all 200k access token it had left on our servers unrevoked)
> - What the average rating has been (but you need a way to rate clients!)
Not something 99.9% of people will do meaningfully, see appstore ratings and bridgading of apps to tank their scores.
> - How many Flag activities have been submitted for this client (you need a way to report clients)
You can't Flag a non-activitypub JSON document. The majority of fediverse software doesn't support multi-modal moderation reports, Pixelfed is one of the few that does.
> - Reviews of the client (you need a way to write a review of a client)
See prior note on App Stores.
> That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
Sure, maybe, but it needs to reference a CIMD at a specific content-hash. Otherwise I can attack that system by changing my metadata to gain more access
-
You asked this here: https://activitypub.space/topic/fd53b73d-bf92-4e81-a5ae-5a681e4aacd4/flag-activity?_=1768647932631
There has been no changes in status from what I last said, because I get almost zero time to work on AP T&S. I can probably explain Flag activities better in a call or something than quickly in text.
-
@julian @pfefferle ActivityPub spec says IDs are URIs, I think that means non-ascii characters should always be encoded.
Mitra rejects IDs that are not URIs, most of the time this doesn't cause any issues (WordPress was the only notable exception).
-
@pfefferle@mastodon.social I'm frankly surprised I ran into a side effect of this so soon after you updated the site :laughing:
Either the PR is to be reverted or perhaps WP should handle requests to the URL encoded address :shrug:
But after briefing myself on the root cause, it does seem weird that there exist actors with unicode in their ID. Might be if that is the case you should disregard them as non-compliant, who knows.
-
@julian should work again :(
