Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Re: Expanding collections on delivery

Technical Discussion
4 3 0

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • Expanding collections on delivery

    Technical Discussion activitypub
    15
    0 Votes
    15 Posts
    9 Views
    @silverpill @technical-discussion it's part of the outbox delivery algorithm, which bridges between c2s and s2s. the intention is that the outbox publishes activities via c2s, but then optionally delivers based on addressing properties via s2s(this ends up having other issues in practice due to the lack of an envelope, but at least the intent of "relevant activities should trigger notifications for relevant entities" makes sense, per 6.1 clients "look at" some relevant props)
  • Browser.Pub and Anubis

    Technical Discussion browserpub anubis
    13
    1 Votes
    13 Posts
    12 Views
    @julian perfect!
  • ActivityPub API Client Reputation

    Technical Discussion
    10
    0 Votes
    10 Posts
    29 Views
    @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
  • 0 Votes
    2 Posts
    6 Views
    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.