Notices by silverpill (silverpill@mitra.social), page 24

@FenTiger @steve Done: https://codeberg.org/silverpill/feps/src/branch/main/d85d/fep-d85d.md#retrieving-objects (I've also added many new recommendations)

@frogzone Looks like SVG <title> element is an equivalent of alt text in <img> tags:

https://css-tricks.com/accessible-svgs/

Have you tried adding it?

Also, I think text would be better than a glyph, from accessibility perspective

@nimda @p @walterebert

@tadano @mint Yeah, I didn't forget about these. Was busy with protocol work and mitra 3.0 but now I'm returning to working on features.

@FenTiger @steve I'm hesitant to use RFC-2119 keywords because this is meant to be a guide (opinionated), rather than a normative document.

But I agree, this is very important. Maybe content negotiation deserves its own FEP

I'm collecting various ideas on improving ActivityPub developer experience. Currently they are in a FEP format, though that might change: FEP-d85d: ActivityPub for developers.

The goal of this document is to provide information that is useful for beginners but can't be found in the ActivityPub spec, simplify the protocol while improving interoperability, and address common misconceptions. It was partially inspired by ActivityPub Minimal Core by @steve

#FediDevs

@mint @tadano Nice. I'll try to do something similar

@tadano It will be replaced the next time you install deb package. If you want it to be preserved during upgrades you can install the modified frontend separately and then change web_client_dir parameter in config file. Not great, I know.

How they do it in Pleroma?

@algernon Can Forgejo actors be followed? I tried to Follow @algernon, the server responded with 500 (I don't know what the response body was but can get it if needed)

@liaizon

@hongminhee Yeah, I'm also thinking about this a lot lately. We need something like MDN but for ActivityPub

>Resources for Developers, by Developers

@dansup @mario FEP-5624 is not my proposal, it was submitted by Mastodon devs (they are present on SocialHub but not very active). I don't even like it, in my opinion Conversation Containers by @mikedev is better because it can be used for public and private groups too.

I'm participating in several AP / fedi matrix chats, but discussions there are less productive because of their ephemeral nature. Besides being good place for long thoughtful discussions, SocialHub also supports ActivityPub (beta, via Discourse plugin) so you can test interop between it and your groups implementation (if you support FEP-1b12).

@algernon signature property is used for LD signatures, which are deprecated. Some implementations still add them but they are not required for federation.
However, if you have a use case for embedded signatures, consider implementing data integrity proofs as described in FEP-8b32. This is an alternative to LD signatures based on modern web standards.

@heluecht @jwildeboer Data integrity proofs (FEP-8b32) are an alternative to LD signatures, based on current web standards.

Conversation Containers (which rely on integrity proofs) work as you described - comments are relayed by the conversation owner

@trwnh At least one

@algernon

>Do I need to implement outbox? I'd prefer not to implement outbox if I can avoid it.

outbox is required by standard, but it can be an empty collection

@Hyolobrika https://github.com/Fediseer/fediseer

@dansup @mario Most interop and FEP discussions happen on SociaHub. Comment controls are discussed in this thread: https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723 (you can find an overview of the current work at the end of it)

@julian @alex-mehr @trwnh

>There's no guarantee that a collection would present items in chronological vs. reverse chronological order — are you checking the timestamps and reversing as needed?

The ordering can be specified by some property of Collection

>Wouldn't you need to paginage through the entire collection anyway?

The client will fetch pages until it finds an item that has already been processed.

> I think that informs why I set up topic synchronization in this manner, and why my idea of context collections contain only objects; to me, activities don't really mean much at all.

I'd prefer context to be a collection of objects too, as long as there's a way to retrieve activity history.

Activity-based sync seems more natural to me. I think ActivityPub can be better understood not as a protocol for social networking, but as a distributed database where nodes sync datasets by sending messages over the network. Messages are activities, datasets are collections. When I send a Follow activity and your server responds with an Accept, followers and following collections are updated on both sides (or their equivalents if you don't store activities and collections). More generally, any activity delivery can be viewed as a synchronization of outbox collection.

I think such change of perspective can greatly improve DX and provide a solid foundation for further protocol extensions

@jupiter_rowland I can see it, thanks.

@mikedev this is the URL of inbox where I'm sending Follow activity: https://streams.elsmussols.net/.well-known/apgateway/did:key:z6Mkmc3YmgUu5jTyhc6YqC8VjnMwmFtdjFFA45MHTqyBFaA2/actor/inbox

Same result with Like activity, the server responds with 403

@giacelvecio @streams

@julian Even if context contains objects and not activities, synchronization can be done by requesting all activities where Activity.target == Object.context (from the outbox perhaps?)

@julian

I implemented fetching of context (manual) - my server simply reads the latest N items from the collection.
While working on that I realized that synchronization can be done differently. If context collection contains activities that modify it (such as Add and Remove), in reverse chronological order, the client can re-construct the current state by fetching them and applying one by one. There is no need to compute digests with this approach, remembering latest activity ID would be enough.