FEP-9f9f: Collections has been published:
https://codeberg.org/fediverse/fep/src/branch/main/fep/9f9f/fep-9f9f.md
It seems to cover the basics, let me know if I missed anything.
RE: https://socialhub.activitypub.rocks/ap/object/4f422d20555601ca6e73b35b830cf74d
I know there is some ongoing work, eg. https://socialhub.activitypub.rocks/t/fep-07d7-a-custom-url-scheme-and-web-based-protocol-handlers-for-linking-to-activitypub-resources/3588.
Some people will argue against this, but the Atmosphere is (slowly) decentralizing (https://stefanbohacek.online/@stefan/116126040489956521) and it will soon run into the same issues we're dealing with, like being asked to log in when you click a link to a post that's not on your server/AppView/what have you.
I'm sure they will figure this out, with their deep crypto VC money pockets, but if we can figure this out first, it could really give us a major advantage.
Hello! This is a discussion thread for the proposed FEP-07d7: A Custom URL Scheme and Web-Based Protocol Handlers for Linking to ActivityPub Resources. Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addressed. Summary This specification addresses sometimes difficult interactions with ActivityPub resources hosted on remote servers. It defines a custom URL scheme which can be used by custom web-based protocol handlers to route hyperli...
App-centrism is a re-centralization force in the #ActivityPub fediverse.
For the #fediverse the accepted app-centric #SocialNetwork work method is a decentralized NPM-like dependency hell waiting to happen.
Apps that introduce extensions become owners of parts of the specs when they become de-facto standards. We can only hope for responsible #ownership, and that the project stays around to keep their #design docs and code in the air.
The #FEP and the #SocialCG are two points of #centralization we find acceptable to help mitigate protocol decay and tech debt. It is not ideal, but a bandaid to keep an utterly fragmented developer ecosystem together.
The people who do most of this holding together are volunteers that can be counted on one hand. They may burnout and leave any day, in typical #FOSS fashion.
#SX investigates the concept of #GrassrootsOpenStandards, where the standardization process matches social dynamics that exist in our #commons.
@phnt @happy-programming @Profpatsch
What was also interesting re: #GNUSocial is the unfortunately retracted #ActivityPub #FEP on Unbound Groups i.e. groups (or organizations) that are not bound to a single instance.
See #FEP2100 at https://codeberg.org/fediverse/fep/src/branch/main/fep/2100/fep-2100.md
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Link—and PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
#fedidev #ActivityPub #ActivityStreams #ActivityStreams2 #AS2 #PropertyValue
Description When Fedify serializes actor attachment properties containing PropertyValue items (used by Mastodon for profile metadata fields), the resulting JSON-LD uses schema:PropertyValue as the ...
FEP website now displays the number of implementations for each implementable proposal:
https://fediverse.codeberg.page/fep/final/
These numbers are based on the information that authors provide in the "Implementations" section of a proposal.
By default, proposals are informational, so authors need to opt in by adding type: implementation to the metadata block.
@silverpill @raphael @julian @mariusor
The killer app for the fediverse is not nomadic identity. That is either a protocol capability or may refer to an Identity Management app, a solution design.
Problem is, it is no use discussing here. No convergence takes place, other than spontaneous / random convergence. But it does not lead anywhere, not to a common consensus. Not to robust foundations to build on without continuous worries that things break. Microblog communications does not support this, and lacking that support manual processes are needed.
Even the #ActivityPub #FEP only offers convergence to certain extent. The process is a band-aid, a best-we-have.
In analogy of the horserace, spontaneous convergence and ad-hoc alignment on FEP puzzle pieces by implementers equates to the horseback riders figuring out some basic rules to avoid serious accidents. But this FEP adoption at the same time warps the track, hems them in, alters reality and the future.
Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.
I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:
FEP-fc48: Generic ActivityPub server
This kind of server:
- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.
I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.
silverpill
Stefan Bohacek
🫧 socialcoding..
洪 民憙 (Hong Minhee) 
naturzukunft
The Void ザ・ヴォイド