silverpill

@ozoramore_dev It's a cache, you can update it using this query: https://codeberg.org/silverpill/mitra/src/commit/8b5c382bc3c0ed9e536e66ce1f81045aef98e6d9/mitra_models/src/profiles/queries.rs#L90-L120

It updates only a single user, but I think removing WHERE actor_profile.id = $1 should be enough to update all users.

@Floppy I've also heard that Prismo is being built on Fedipub. That's cool!

@ug I thought that it is used by ActivityPub-for-WordPress, but didn't find it among dependencies. Perhaps there are other projects that rely on it?

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

The content attribute is to contain the WebFinger handle of the author's fediverse profile, i.e. username and domain separated by an @-symbol. A leading @ can be included and ignored when processing. This format was chosen for its user-friendliness, as this style of handle is what users would be used to seeing and typing when using most fediverse software.

This choice was criticized a lot when the feature was introduced. Meta tags are primarily read by machines, not humans, so user-friendliness shouldn't be a concern. Reliability, on the other hand, is worth taking into consideration. preferredUsername and the user part of a handle can be changed at any time. Actor ID is a more stable identifier and in my opinion is a better match for the fediverse:creator tag.

@hyc This rule doesn't seem to be used in practice

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

@harblinger

>>>reply tagging

What do you think about federating these as quotes? Mitra supports multiple quotes per post (imageboard use case was taken into consideration when the feature was developed).

>>>(Cross-thread) markdown copy and quote posting

If you use the [[]] microsyntax, the link will be parsed as a quote:

[[https://wizard.casa/objects/019fc0a1-a9ef-7731-997e-40dd6864f469|>>1234567]]

chan-fe v0.2.0 release

yet another slop-fe, but it's been my daily driver
>>526cf444 (Cross-thread) Previous thread

https://git.wizard.casa/nak/chan-fe/releases/tag/v0.2.0
Highlights:

- /dm/ board for your direct messages
- Draggable compose panel, allows for multi >>reply tagging
- Link menu on posts, exposes originating post URL, >>(Cross-thread) markdown copy and quote posting
- More configurable (video looping, mute defaults, auto-refresh options)
- Multi-account drifting: sign into multiple accounts across instances and easily switch
- Mitra XMR subscription support

Special thanks to @silverpill for upstreaming some API changes to Mitra v5.8.0 which reduces API hits by a lot

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

@phnt What I want is:

handle_incoming() ->
  handle_incoming_activity_type_asdf_object_type_xyz_for_real_this_time()

The authors of Versia protocol tried fix ActivityPub by giving better names to everything: https://versia.pub/entities/unfollow

Looks good IMO

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

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

@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).

@mbajur Can @mbajur be followed?

@graf There was a problem with sessions - Husky didn't handle token expiration correctly: https://github.com/captainepoch/husky/issues/162

But I don't use it myself, maybe this has been fixed already

@hongminhee @drfed

We are building a tool that checks whether an implementation supports a given FEP correctly. That saves developers from verifying everything by hand.

I am interested in this. What kind of tool you're building?

We have explored two approaches: Gherkin files (example: FEP-8b32) and JSON schemas (example: FEP-9967).

@helge worked on a tool that automatically validates activities against a JSON schema. The site is down now, but the code is available here: https://codeberg.org/funfedidev/schemas

I think this was a promising project.

I have not heard from Angus for nearly a year. The current maintainer seems to be @pmusaraj