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

Using the ActivityPub API for cross-server interactions

Technical Discussion
5 3 5

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @evan thanks!

    I would attend but unfortunately a winter storm hit and I'm at home watching three kids today 😑

    read more

  • @julian The ActivityPub API Task Force has a meeting today at 11AM EST. https://meet.jit.si/activitypub-api

    read more

  • read more

  • @julian hmm, I believe it tries to make each AP call from the browser first, then falls back to a cloudflare worker if that fails.

    I just checked the cf worker and found this gem in it, so that might work for you too

    read more

  • 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 😅

    read more

  • 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.

    read more

  • 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?

    read more

  • 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?

    read more
Post suggeriti
  • 2 Votes
    6 Posts
    8 Views
    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.
  • 0 Votes
    1 Posts
    2 Views
    "Critical concept: IRIs are opaque identifiers. You cannot infer meaning from the string pattern — only by dereferencing and inspecting the data." [1] This applies to URIs too. Sadly, almost no #ActivityPub implementations use this principle. Multi-tenant servers and simple account portability (with personal domains) would be relatively easy if they did.🙄 It is what it is.../cc @melvincarvalho [1] https://socialdocs.org/docs/concepts/uris-iris-linked-data/
  • Happy New Year!

    Technical Discussion
    1
    1
    0 Votes
    1 Posts
    2 Views
    Happy New Year! Hope you all had a good holiday. It’s shaping up to be a great year on the open social web! We’ve been busy working on new features, internal improvements, bug fixes, and exploring new networks over the last couple months. Here are the noticeable changes on the bridge since our last update: DM notifications for interactions from non-bridged users (more) Mastodon to Bluesky support in Bounce (more) Expand blocking to Bluesky blocklists, multiple at once, web UI, and more… Support setting Bluesky handle back to the default *.ap.brid.gy (more) More support for fediverse => Bluesky pinned posts Make images/videos on Bluesky more reliable: Refresh them periodically Handle the same file at multiple URLs Upgraded to a paid CloudImage account for proxying Threads images/videos Customize Bluesky labels based on keywords in fediverse content warning (thanks @KDederichs!) Improve GoToSocial compatibility Bridge Web Monetization wallet addresses For Bluesky profiles bridged to the fediverse, make the link back to Bluesky “verified” (green check) in Mastodon Add support for new (invisible) website field in Bluesky profiles Web UI: improve handling of IDNs (domain names with emoji) and punycode RSS feeds: support application/rdf+xml Web UI: reload profile on login Bug fixes: …for race condition on writing to Bluesky repos …for bridging Bluesky handle changes to fediverse Webfinger address …for bridging web posts, replies, etc after we’ve already seen them …for deleting bridged fediverse profiles on some servers …for bridging Bluesky profile pictures to the fediverse …for links in post text When there’s an unbridged dependency, only skip that one protocol, not all Add missing PropertyValue in AS2 @context …for duplicated images in posts bridged to Bluesky Internal: Bluesky: Reliability improvements for firehose server/client Scale past ~10qps bottleneck in allocating sequence numbers (more) implement listBlobs Expand continuous deploy flags Various cost optimizations added up to savings of 40-50%: As usual, feel free to ping us with feedback, questions, and bug reports, and please support us on Patreon! You can follow the now label on GitHub to see what we’re currently focusing on. See you on the bridge!
  • 0 Votes
    2 Posts
    3 Views
    @reiver well, a short summary;Public Spaces was full, the Social CG October meeting had 36 attendees, the November meeting was the dev meeting, the December meeting had 40 people who partly prepared #39c3 which then had 16.000 attendees.Happy New Year anyone – and thank you to all the volunteers who made this possible. We do also have german meetings, next one is in 2 weeks, et al. tell me if you are interested.