@sun So, I think the biggest problem with this proposal is that it requires a publicly accessible HTTP server. Is there a good reason for that?

WebXDC, for example, is designed for offline first apps. I am reading WebXDC docs right now and it seems to be compatible with ActivityPub. Maybe we should work on this instead?

@pernia @kirby You said it's only two lines if we switch to another argon library. That's beautiful

@phnt @theorytoe @sendpaws @caohuak

>I nominate everybody in this thread.

I am completely serious - only Dark Fedi people can be trusted with maintenance of the most important communication protocol of the 21th century.

@julian Hello, are you still working on interactionPolicy FEP?

Updating FEP-5219: Groups and permissions: https://codeberg.org/fediverse/fep/pulls/908

I added two flags that indicate whether a group is private, semi-private or public: canFollow and canParticipate. These flags are similar to ones used in interactionPolicy pattern but I think interaction policies don't scale well.

There is now a thread on SocialHub if you prefer it for FEP discussions: https://socialhub.activitypub.rocks/t/fep-5219-groups-and-permissions/8855

#fep_5219

@streamsgarden

Compatibility patches are being prepared for streams and hubzilla - the only other projects which support the conversational fediverse.

You're quick to forget that someone painstakingly documented conversation containers, implemented them and spent two years promoting the feature to other developers.

No good deed goes unpunished

@potatomeow This is because you're on Mastodon

Mastodon 4.7 beta supports FEP-521a: Representing actor's public keys and FEP-8b32: Object Integrity Proofs (inbound only for now)

I also see FEP-8967: Generating link previews for attached links in the changelog.

It looks like FEP process is actually working?

RE: https://mastodon.social/users/MastodonEngineering/statuses/117071692327950548

@doesnm Also Request activity should work well with iroh-gossip https://docs.iroh.computer/connecting/gossip

@doesnm I want to try this in client-to-server interactions first, as a replacement for proxyUrl: https://codeberg.org/silverpill/minimitra/issues/9

minimitra sends a Request activity to server -> server adds the fetched object to actor's inbox

@sun @deutrino

5. https://mitra.social/objects/019fc6cd-666a-7772-ba2f-2e711a8e8f69

The biggest problem for peer to peer ActivityPub is the fact that ActivityPub is primarily a "pull" protocol. You need to fetch a remote actor before interacting with it. This is not feasible in the environment where nodes are intermittently online.

What if we used a special activity to request objects? I've described this idea in more detail in Asynchronous object retrieval:

https://codeberg.org/silverpill/feps/src/branch/main/aef6/fep-aef6.md

I think this mechanism, if combined with self-authenticating objects, should make ActivityPub compatible with store and forward protocols.

#p2p #dtn #fep_ef61

I added a list of recommended libraries to the ActivityPub developer guide:

https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#libraries

- activity (Go, used in GoToSocial)
- Fedify (JavaScript, used in Hollo and Ghost)
- Fedipub (Ruby, used in Manyfold)
- activitypub_federation (Rust, used in Lemmy)
- APx (Rust, used in Mitra)

This list only includes libraries that are actually used somewhere. Libraries that are not used, or used in projects with too few users are not included.

#fedidev #activitypub

I've updated the section describing the authentication of embedded objects in FEP-fe34 (Origin-based security model):

https://codeberg.org/fediverse/fep/src/commit/9ad3767987dae7e51d647768b655e93b82881343/fep/fe34/fep-fe34.md#embedding

It now covers the case where a signed embedded object is attributed to another local actor. That happens in federated groups and conversation containers where signed activities may be wrapped in Announce or Add activities.

Previously, the recommendation was to reject such activities when submitted via C2S API. Now the FEP recommends authenticating embedded objects (e.g. by looking up their IDs).

Another important change: anonymous objects are not ownerless anymore. Such object has the same owner as its parent object. It also inherits origin from its parent object, though that follows from the definition.

#fep_fe34

FEP-5219: Groups and permissions has been updated:

https://codeberg.org/fediverse/fep/pulls/895/files

- The items in the affiliations collection are now required to be full Relationship objects with id, attributedTo and object properties. I think these objects should be self-contained and exist independently of the collection.
- Access to the collection MAY be limited (for example, when the group is private).

#fep_5219

Private groups

Lately, I've been seeing various people claiming that fediverse doesn't have private groups. They often point to some task force at w3c that is supposedly working to fill the gap.

However, fediverse has had private groups for a very long time:

- Hubzilla channels. This project probably had private groups before ActivityPub. The implementation was later adapted for ActivityPub and refined in subsequent forks, Streams and Forte. It is now partially documented in FEP-171b: Conversation Containers.
- Smithereen groups. This implementation is documented in FEP-400e: Publicly-appendable ActivityPub collections (published in 2021) and FEP-db0e: Authentication mechanism for non-public groups.
- Lemmy communities. Private groups were proposed in Lemmy RFC 0005 and have been implemented in the development version. There is a test instance running this version (Lemmy v1.0b) at https://voyager.lemmy.ml/

There are probably other implementations that I am not aware of.

#Hubzilla #Smithereen #Lemmy

@sun @deutrino

>can you tell me more about where I can read about your work with p2p and your idea for adapting forgefed? I'm interested.

1. My experiment with ActivityPub over Syncthing: https://mitra.social/post/019de9a2-7769-7713-85c9-ad8e8599268d
2. ActivityPub & iroh: https://mitra.social/post/019f8116-59de-71f2-8c56-2e87e32c2859
3. I'm currently working on federated groups in Mitra and so far they seem to be compatible with FEP-ef61 and therefore with P2P ActivityPub
4. ForgeFed has many similarities with federated groups: https://codeberg.org/ForgeFed/ForgeFed/issues/324

@elle

also, what do you mean by corporate takeover?

This picture: https://pl.fediverse.pl/objects/2fee01c3-d3d2-4443-9dd5-6d4ec84580c4

(thanks @mkljczk)

FEP-0806: Simple client-side encryption

https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md

The FEP now includes the recommended algorithm parameters.

I consider it finished but I don't plan to continue working on my implementation or publishing to the main FEP repository. It would be better to focus on group messaging with forward secrecy (MLS or similar).

#fep_0806 #e2ee

Setting up a Forgejo instance: https://code.mitra.social/silverpill/mitra

It will be mirroring repositories related to the #Mitra project. I don't plan to migrate from Codeberg right now, but it wouldn't hurt to have a self-hosted instance in case they decide to enforce the new anti-crypto policy.

This will also allow me to test the implementation of federation in Forgejo.