silverpill

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

@phnt @icedquinn mitra builds with 1.85 - the version of rustc that is shipped with debian stable. There is a lot of garbage in the ecosystem that requires latest rust but if you know how to navigate it you can build complex software with conservative requirements.

@julian @z9mb1 There are already two Rust frameworks...
Also some parts of the code look very familiar to me, which is not surprising given that the project is vibe coded (= plagiarized).

@iftas @smallcircles

@julian @skavish Yes, an FEP can cover a non-technical topic too.

@phnt I am wondering if various Add and Remove activities should also be renamed. Wouldn't it be easier if we had AddFeatured instead of Add?

@Willow @gailen It's a Mastodon API client.

@mobilizon

Group
Every Mobilizon group is a Group.

Oh, interesting. Where can I learn more about it? Are Mobilizon groups interoperable with Lemmy groups?

@gailen I think it's already part of fediverse 😆

https://plspace.space/

@mooooooo It probably refers to HTTP signature algorithm

Btw I wrote a guide that explains how to do AP: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md

@maddyunderstars @technical-discussion

Do you think I should elaborate more on this?

Yes. I think an example from FEP-1b12 realm will be helpful. Can actors from FEP-1b12 "moderators" collection be considered authorised actors?

There's a footnote on what authorised actors are, tldr it's however you decide to do it.

In that section, you mention "the 'invite-actor'". Does this term refer to InviteCode.attributedTo actor?

It's a side effect of Add currently. Should it be the other way around? I guess Create<Note> adds to the outbox, so it would make sense.

I would expect that an invite code is Created first, and then Added. At least when using ActivityPub API clients.

@maddyunderstars

Activities on InviteCodes

When an activity modifying the InviteCodes for an Actor is received, the Actor MUST ensure that the activity is being performed by an authorised Actor.

Did you mean "modifying the invites collection of an Actor"?
How to ensure that activity is being performed by an authorized actor?

To create a new InviteCode for an Actor, a standard Add activity is sent to the Actor the InviteCode is associated with.

Is there a Create(InviteCode) activity? Or invite code is supposed to be created as a side-effect of Add activity?

@technical-discussion

I think it's fine to use a different type. What I wanted to point out is that context property is for grouping related objects, and that there is another property that does exactly you want - relationship.

we're modeling a one-way relationship, not two way.

In a two-way relationship, there is an expectation that another Relationship object exists representing a reverse claim.

Is there another way around this issue that DOESN'T require Object Integrity Proofs?

I am not sure if integrity proofs really solve this problem... It's hard to tell without knowing who signs what (I didn't find that information in the FEP).

@caohuak @graf Mastodon returns an empty string when display name is not set. Maybe Mitra should do the same.

Endorsements MUST have a context property, which contains a context URI that identifies the nature of the endorsement.

This usage conflicts with FEP-7888. If you're modeling Endorsement after Relationship, perhaps relationship property would be more appropriate?

Endorsements MUST have a proof property, which contains an Object Integrity Proof as defined in FEP-8b32. This is required to prevent someone from changing an endorsement maliciously after it has already been accepted.

Who generates this proof? Who owns the Endorsement object?

This information is crucial for the verification of proofs, see https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#proof-verification.

Server admins MAY make server-level endorsements on behalf of the server's Application actor.

This statement links to FEP-2677, which requires discovery through NodeInfo endpoint. Consider using FEP-d556, which recommends on Webfinger instead.

@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

@smallcircles @eest9 Yes, not everyone wants to be on a global public square. Small private zero-cost friend-to-friend networks should also exist, and for those p2p is a good architecture.

@eest9 I think we can have a network that supports both kinds of structures at the same time. Big federation where resources are meant to be pooled and small federation where people use their own offline-first nodes.

@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