FediForumTM

Upcoming Events

Project Map

@fediforum@mastodon.social
FediForum March 2024:

Distributed Press & P2P ActivityPub

/2024-03/session/4-e/

Convener: @mauve@mastodon.mauve.moe

Notes-taker(s): @f@todon.nl

Participants who chose to record their names here:

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

(Quick round of intros)

  • mauve on fedi since 2018, working on distributed press
  • fauno he/him. coop in argentina, tech lead of sutty.
  • narF: fan of fediverse and p2p
  • @fihu, on mod team of norden.social, into seeing more
  • Jeremiah, they/he, Stockholm, working on NLNet grant. Not using AP, curious aobut other options. Loved demo and want to publish static site
  • Non-attributed: got a startup, building on AP. Started with Mastodon, wanting to go private and figuring out community strategy
  • Akhilesh, software engineer at distributed press. worked on inbox and reader. run p2p labs orgs where making a browser cqalled peersky
  • Non-attributed: new dev to fedi. Looking to contribute to something. Looking at content creator incentivesx
  • Non-attributed: in a noisy env

m: answers, comments? we can also show more stuff we’re currently polishing

Can you summarize what you’re doing

There are many P2P protocols with different affordances and limitations, so switching between then can be annoying. So Distributed Press (DP) makes it simpler to support P2P protocols without dealing with the details of each protocol. Any protocol that has an URL can be published through DP. IPFS ended up being a little too slow for our uses, and sometimes we can’t support specific features of protocols, like IPLD.

Static site publishing has worked fine. To support readable domain names we have a custom nameserver that supports DNSLink, matching unreadable hashes to rememberable user names (ie. ipns://distributed.press).

A static site is published by sending a tarball to DP and assigning some DNS records to it.

We support IPFS, Hypercore and Bittorrent, are we want to add support for Veilid and Iroh

Is censorship avoidance a main preocupation/motivation?

Our motivation is more on making it simpler to have content available.

How are you actually using IPFS and dweb protocols?

  • Static site publishing

  • Sutty’s motivation:

    • It’s a worker coop and a cms for static sites
    • Build static sites for NGOs/Collectives/Activists
    • Want sites to be more resilient
    • Been looking at dweb protocols, once published avalable and easily archivable
    • Related to censorship but focused on resiliency
    • Most sites when they went down it was due to lack of maintenance rather than censorship

With AP we can add social interactions to static websites. We are working on adding support to blog comments to themes, but the Sutty CMS with the Social Inbox currently supports receiving them, moderating instances/actors/comments so they can be later be publishing.

We were going initially with indieweb’s webmentions but we decided to focus on AP because it enabled more features for us. Enabling websites to have outreach to the Fediverse and have their content distributed there.

Since AP is composed of JSON objects, we’re also storing them as static files which can be published through P2P protocols. We’re using FEP fffd so we can achieve better backwards compatibility. Objects are the same but URLs change protocol schemes and are inter-linked. The Social Reader supports this through gateways and P2P-native browsers seamlessly. (The instance needs to support FEP fffd/1042 for this to work, the Social Inbox does.)

This is potentially useful for mesh networks and offline communities, because you can pull posts from the Reader local cache.

For the Reader we had to use a CORS proxy to be able to load public outboxes from other instances.

Mastodon doesn’t use the outbox so when you look up a profile or follow an account, you don’t get previous posts, but a small message saying you need to look elsewhere.

The Social Inbox and Reader have minimal dependencies, so they could be a good start for other projects.

In Mastodon you have a huge database that forms the public timeline and you get more exposed to hate. The Reader has localized timelines (we’re doing a write up soon!)

In P2P you don’t have everything so have to think local.

Static site AP publishing

What we did is split the AP/AS spec between things that be generated/hosted statically, so Actor, Activity, Outbox objects are JSON files, and the Social Inbox sends notifications to followers and receives+processes follow requests, likes, boosts, reports.

Static site publishing:

  • Activities being json made it easy to publish to p2p protocols
  • Only live bit was social inbox for likes/follows/comments
  • Most of the spec used satic files so the jekyll plugin generates these from the site post
  • Also publishes actors

Question for the room: Do you think this would be interesting for your projects?

There’s a need for static sites to talk to fedi. Jekyll is a good start

dweb stuff seems more academic since there’s fewer clients and users

https://github.com/RangerMauve/staticpub.mauve.moe/

Is anything we’re building potentially useful to your projects? Can they interact?

j: There’s a need to figure out how static websites can interact with the Fediverse so it’s cool to hear about this

m: it’s doesn’t need to be jekyll. the social inbox takes care of sending AP notifications, and receiving and processing followers/likes/boosts/reports so other ssg could have their own plugins similar to jekyll-activity-pub. we also have webhooks to re-deploy when an activity is received or whatever you need (the sutty moderation queue uses webhooks to interact with the social inbox). also the staticpub repo demos what kind of files you need to generate to support static fediverse publishing. https://github.com/RangerMauve/staticpub.mauve.moe/

Sutty is available for hiring and can convert an existing website to a static website to gain resiliency and also enable these features :)

We’re available for custom implementations (ie. other SSGs)

The Social Inbox and Distributed Press can be deployed with Ansible. It comes with Gardenfence as a default blocklist and Sutty CMS implements a few more.