silverpill

If you want to run your own node, check out mitra (its i2p docs). This software powers mastodon.i2p

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 Webfinger instead.

One can also follow hashtags at https://relay.fedi.buzz/

@benpate

Also, Gilles makes a strong point to just use the word "Trust" -- it's simpler and better known around the world. What do you think of that, instead?

I prefer "endorse". IMO "trust" is too vague and often used in discussions related to security.
In the user interface, the different flavors of "endorse" could be described using other words.

@phnt I wouldn't say that introducing a new vocabulary is a trouble (unless you care about JSON-LD, which requires deploying a website every time you invent a property or type)...

But you're right, it's better to use prefixes - I already started doing it in my FEPs. Prefixes could be dropped once a FEP is finalized.

I don't know. Why do you want to use the existing vocabulary?

A descriptive activity name leads to a better developer experience:

- You can look at activity and instantly know what action is being performed.
- Servers that implement your FEP don't need to use heuristics, look up object, etc. to figure out what's going on.
- Servers that don't implement your FEP silently ignore unsupported activities, without wasting any resources.

As it stands now, Accept, Reject and Undo are identical to activities related to a follow relationship.

I suggest picking more descriptive names for activities:

- OfferEndorsement
- AcceptEndorsement
- RejectEndorsement
- UndoEndorsement

And maybe Endorse should be an object instead of activity? An endorser may want to update the endorsement metadata (content, image, tags).

When the fourth activity appears, the context is checked, C's reply isn't in it, and I proceed without knowing about it. Oops!

I don't understand this part. Is C's reply being dropped?

I think if you encounter an object where inReplyTo is not known to you, that unknown object should be fetched, regardless of context.

this is related to FEP f228.

FEP-f228 specifies a backfill algorithm that works from top-level post down the thread. But it would be nice to provide an algorithm that works for any post in a thread. I'll think about it.

I mean they don't provide any good examples of how this technology could be used.

There is one real use case for ZKP: private payments. It seems that there is no demand for other applications.

POD enables internet users to store and share data that preserve its integrity.

It's not clear how this is better than regular signatures

How do you discover Lemmy communities? Federated categories in Discourse work in the same way, so a tool capable of discovering Lemmy communities should also be capable of discovering Discourse forums.

Discourse has an ActivityPub plugin: https://discourse.org/plugins/activitypub

This plugin, for example, is enabled on SocialHub https://socialhub.activitypub.rocks/ap/about (it's a forum for fediverse developers)

I saw that PR was merged and tried again, but now Lemmy doesn't notify me (community admin) about the follow request, and doesn't send Accept. However, the community subscriber counter increases and private posts are delivered to the follower.

Thanks!

Tried to follow a private community, and I have a problem with this Accept activity:

{"@context":["https://join-lemmy.org/context.json","https://www.w3.org/ns/activitystreams"],"actor":"https://voyager.lemmy.ml/c/privfedtest","id":"https://voyager.lemmy.ml/activities/accept/6a08b817-9dc2-498a-a637-9092c8ea15fc","object":{"actor":"https://mitra.social/users/silverpill","id":"https://voyager.lemmy.ml/activities/follow/3c08aca5-9e41-4d15-b134-326c4bd91bd0","object":"https://voyager.lemmy.ml/c/privfedtest","to":["https://voyager.lemmy.ml/c/privfedtest"],"type":"Follow"},"to":["https://mitra.social/users/silverpill"],"type":"Accept"}

The id inside Accept.object is not the ID of my Follow activity, it's something different. Its origin is not my server:

https://voyager.lemmy.ml/activities/follow/3c08aca5-9e41-4d15-b134-326c4bd91bd0

Hello @nutomic, could you add my instance to the allowlist? I'd like to test federation with private communities.

@julian Hi, what's the status of this? Is cross-posting still done by making a copy of a post?

My understanding from a reading of the relevant section from fe34 suggests a claim of A → B is reciprocal if there is an inverse claim B → A.

Yes, and in my understanding these claims are:

- This actor is authorized to delete/update this object.
- This object is hosted on the server where this actor is an administrator.

But I don't insist on importing this concept.

I would want to point out that keeping with prior art has the benefit of making this FEP much easier to adopt by threadiverse implementors.

I consider myself a threadiverse implementer too, and I don't really like the idea of dealing with ambiguous properties :)

At the very least, could you add inbox and outbox properties to the Application actor example? https://codeberg.org/devnull/feps/src/branch/instance-admins/fep/baf5/fep-baf5.md#instance-actor-and-application-actor

Wasn't aware this was a problem? Figured the redirects would be okay.

The canonical location of a FEP is on Codeberg, but no, it is not a problem.

#2 I suppose supercedes is the incorrect term. It extends fe34, in a way. Would that be acceptable? Definitely not meaning to imply that fe34 is insufficient in any way.

"Extends" is fine, I just think you're describing a reciprocal claim from FEP-fe34, so you could use that term (or maybe FEP-fe34 needs to be updated if "reciprocal claim" is not a good name for this mechanism?)

1. I find the use of attributedTo here confusing, because normally this property is used to indicate who owns an object or a collection, and its value is an actor. I am aware that attributedTo is used in a similar way in FEP-1b12, but it would be better to introduce a new property (administrators) instead of continuing to abuse attributedTo.
2. You say that your FEP supersedes the same-origin assumption described in FEP-fe34, but I think it describes a reciprocal claim, also described in FEP-fe34: https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md#reciprocal-claims. I suggest clarifying which aspect of FEP-fe34 is being superseded.
3. In the section "Security and Authorization" you say "authenticity" but what actually is being verified is a permission.
4. The entire problem of non-same-actor updates and deletes can be avoided by using different activities. For example, Update can be replaced with an annotation activity. Delete can be replaced with Remove (from thread).
5. FEP links lead to w3id.org site, not directly to FEPs.

@julian @rimu Do you want specifically FEP-2677? Please consider using FEP-d556 instead, it is very similar to FEP-2677 but doesn't require NodeInfo. Also, it is FINAL.