#fep

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

Addendum: Another possible outcome of this prototype could be opening an FEP to include additional details inside nodeinfo, such as links to annual reports, membership price, etc.

Does this already exist? Would anyone be interested in helping write it?

Let me know!

#fediverse #FEP #FediAdmins #MastoAdmins

FEP-8b32 (Object Integrity Proofs) is getting updated: https://codeberg.org/fediverse/fep/pulls/839

I added two new requirements:

- Objects identified using fragment IDs SHOULD NOT have integrity proofs. It is enough to secure the top-level document.
- Verifiers SHOULD ignore proofs that use unsupported algorithms and verification methods. This requirement provides forward compatibility, which is important because sooner or later we will need to use different algorithms.

#fep_8b32 #fep #fedidev

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

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.

#fep

RE: https://socialhub.activitypub.rocks/ap/object/4f422d20555601ca6e73b35b830cf74d

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.

#fep

RE: https://socialhub.activitypub.rocks/ap/object/4f422d20555601ca6e73b35b830cf74d

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.

#fep

RE: https://socialhub.activitypub.rocks/ap/object/4f422d20555601ca6e73b35b830cf74d

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.

#fep

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.

#fediverse #mastodon #FediDevs #MastoDevs #FEP #standards

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

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

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

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

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

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

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

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

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

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

New #FEP view:

https://socialhub.activitypub.rocks/t/proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft

#activitypub

New #FEP view:

https://socialhub.activitypub.rocks/t/proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft

#activitypub

New #FEP view:

https://socialhub.activitypub.rocks/t/proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft

#activitypub

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.

#fep #fedidev

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.

#fep #fedidev

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.

#fep #fedidev

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.

FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).

If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.

Implemented FEPs, ranked by the number of implementations that attest support, are:

FEP   Name                                                        #
----  ---------------------------------------------------------  --
67ff  FEDERATION.md                                              18
f1d5  NodeInfo in Fediverse Software                             16
8b32  Object Integrity Proofs                                     7
044f  Consent-respecting quote posts                              7
2677  Identifying the Application Actor                           7
e232  Object Links                                                6
1b12  Group federation                                            6
3b86  Activity Intents                                            6
521a  Representing actor's public keys                            5
2c59  Discovery of a Webfinger address from an ActivityPub actor  5
7888  Demystifying the context property                           5
5feb  Search indexing consent for actors                          5
4adb  Dereferencing identifiers with webfinger                    4
d556  Server-Level Actor Discovery Using WebFinger                4
fb2a  Actor metadata                                              4
ef61  Portable Objects                                            4
8fcf  Followers collection synchronization across servers         4
844e  Capability discovery                                        4
7628  Move actor                                                  3
61cf  The OpenWebAuth Protocol                                    3
c390  Identity Proofs                                             3
400e  Publicly-appendable ActivityPub collections                 3
c0e0  Emoji reactions                                             3
0151  NodeInfo in Fediverse Software (2025 edition)               3
fffd  Proxy Objects                                               2
f228  Backfilling conversations                                   2
fe34  Origin-based security model                                 2
eb48  Hashtags                                                    2
171b  Conversation Containers                                     2
a5c5  Web Syndication Methods                                     2

There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).

It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a  "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.

Feature            #
----------------  --
activitypub       26
webfinger         24
http_signatures   21
nodeinfo          19
json_ld            2
ld_signatures      2
ostatus            2
authorized_fetch   1
atproto            1

If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.

#ActivityPub #Fediverse #Fep67ff #fep

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

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.

Special thanks to @mariusor and @trwnh for their input.

#C2S

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.

FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).

If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.

Implemented FEPs, ranked by the number of implementations that attest support, are:

FEP   Name                                                        #
----  ---------------------------------------------------------  --
67ff  FEDERATION.md                                              18
f1d5  NodeInfo in Fediverse Software                             16
8b32  Object Integrity Proofs                                     7
044f  Consent-respecting quote posts                              7
2677  Identifying the Application Actor                           7
e232  Object Links                                                6
1b12  Group federation                                            6
3b86  Activity Intents                                            6
521a  Representing actor's public keys                            5
2c59  Discovery of a Webfinger address from an ActivityPub actor  5
7888  Demystifying the context property                           5
5feb  Search indexing consent for actors                          5
4adb  Dereferencing identifiers with webfinger                    4
d556  Server-Level Actor Discovery Using WebFinger                4
fb2a  Actor metadata                                              4
ef61  Portable Objects                                            4
8fcf  Followers collection synchronization across servers         4
844e  Capability discovery                                        4
7628  Move actor                                                  3
61cf  The OpenWebAuth Protocol                                    3
c390  Identity Proofs                                             3
400e  Publicly-appendable ActivityPub collections                 3
c0e0  Emoji reactions                                             3
0151  NodeInfo in Fediverse Software (2025 edition)               3
fffd  Proxy Objects                                               2
f228  Backfilling conversations                                   2
fe34  Origin-based security model                                 2
eb48  Hashtags                                                    2
171b  Conversation Containers                                     2
a5c5  Web Syndication Methods                                     2

There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).

It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a  "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.

Feature            #
----------------  --
activitypub       26
webfinger         24
http_signatures   21
nodeinfo          19
json_ld            2
ld_signatures      2
ostatus            2
authorized_fetch   1
atproto            1

If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.

#ActivityPub #Fediverse #Fep67ff #fep

Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.

FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).

If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.

Implemented FEPs, ranked by the number of implementations that attest support, are:

FEP   Name                                                        #
----  ---------------------------------------------------------  --
67ff  FEDERATION.md                                              18
f1d5  NodeInfo in Fediverse Software                             16
8b32  Object Integrity Proofs                                     7
044f  Consent-respecting quote posts                              7
2677  Identifying the Application Actor                           7
e232  Object Links                                                6
1b12  Group federation                                            6
3b86  Activity Intents                                            6
521a  Representing actor's public keys                            5
2c59  Discovery of a Webfinger address from an ActivityPub actor  5
7888  Demystifying the context property                           5
5feb  Search indexing consent for actors                          5
4adb  Dereferencing identifiers with webfinger                    4
d556  Server-Level Actor Discovery Using WebFinger                4
fb2a  Actor metadata                                              4
ef61  Portable Objects                                            4
8fcf  Followers collection synchronization across servers         4
844e  Capability discovery                                        4
7628  Move actor                                                  3
61cf  The OpenWebAuth Protocol                                    3
c390  Identity Proofs                                             3
400e  Publicly-appendable ActivityPub collections                 3
c0e0  Emoji reactions                                             3
0151  NodeInfo in Fediverse Software (2025 edition)               3
fffd  Proxy Objects                                               2
f228  Backfilling conversations                                   2
fe34  Origin-based security model                                 2
eb48  Hashtags                                                    2
171b  Conversation Containers                                     2
a5c5  Web Syndication Methods                                     2

There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).

It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a  "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.

Feature            #
----------------  --
activitypub       26
webfinger         24
http_signatures   21
nodeinfo          19
json_ld            2
ld_signatures      2
ostatus            2
authorized_fetch   1
atproto            1

If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.

#ActivityPub #Fediverse #Fep67ff #fep

Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.

FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).

If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.

Implemented FEPs, ranked by the number of implementations that attest support, are:

FEP   Name                                                        #
----  ---------------------------------------------------------  --
67ff  FEDERATION.md                                              18
f1d5  NodeInfo in Fediverse Software                             16
8b32  Object Integrity Proofs                                     7
044f  Consent-respecting quote posts                              7
2677  Identifying the Application Actor                           7
e232  Object Links                                                6
1b12  Group federation                                            6
3b86  Activity Intents                                            6
521a  Representing actor's public keys                            5
2c59  Discovery of a Webfinger address from an ActivityPub actor  5
7888  Demystifying the context property                           5
5feb  Search indexing consent for actors                          5
4adb  Dereferencing identifiers with webfinger                    4
d556  Server-Level Actor Discovery Using WebFinger                4
fb2a  Actor metadata                                              4
ef61  Portable Objects                                            4
8fcf  Followers collection synchronization across servers         4
844e  Capability discovery                                        4
7628  Move actor                                                  3
61cf  The OpenWebAuth Protocol                                    3
c390  Identity Proofs                                             3
400e  Publicly-appendable ActivityPub collections                 3
c0e0  Emoji reactions                                             3
0151  NodeInfo in Fediverse Software (2025 edition)               3
fffd  Proxy Objects                                               2
f228  Backfilling conversations                                   2
fe34  Origin-based security model                                 2
eb48  Hashtags                                                    2
171b  Conversation Containers                                     2
a5c5  Web Syndication Methods                                     2

There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).

It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a  "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.

Feature            #
----------------  --
activitypub       26
webfinger         24
http_signatures   21
nodeinfo          19
json_ld            2
ld_signatures      2
ostatus            2
authorized_fetch   1
atproto            1

If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.

#ActivityPub #Fediverse #Fep67ff #fep

Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?

Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.

If there's interest, I'm happy to write up the rest of this as an additional #FEP

@silverpill
@rimu
@evan
@trwnh
@julian
@ricferrer

Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?

Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.

If there's interest, I'm happy to write up the rest of this as an additional #FEP

@silverpill
@rimu
@evan
@trwnh
@julian
@ricferrer

FEP drafting: Am I using “side effects” here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.

#ActivityPub #FediDev #FEP

FEP drafting: Am I using “side effects” here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.

#ActivityPub #FediDev #FEP

@bengo @bhaugen All W3C work is invite-only and permissioned by design.

That's why we have #FEP

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

I added the "Implementations" section and a reference to FEP-844e:

https://codeberg.org/fediverse/fep/pulls/741

There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.

If you have any suggestions, please comment here, on SocialHub, or create an issue.

#fep #fep_0151 #activitypub #nodeinfo

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

I added the "Implementations" section and a reference to FEP-844e:

https://codeberg.org/fediverse/fep/pulls/741

There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.

If you have any suggestions, please comment here, on SocialHub, or create an issue.

#fep #fep_0151 #activitypub #nodeinfo

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

I added the "Implementations" section and a reference to FEP-844e:

https://codeberg.org/fediverse/fep/pulls/741

There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.

If you have any suggestions, please comment here, on SocialHub, or create an issue.

#fep #fep_0151 #activitypub #nodeinfo

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

I added the "Implementations" section and a reference to FEP-844e:

https://codeberg.org/fediverse/fep/pulls/741

There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.

If you have any suggestions, please comment here, on SocialHub, or create an issue.

#fep #fep_0151 #activitypub #nodeinfo

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

Here's another #FEP for representing torrents on activitypub :)

short, sweet, and with a reference implementation and tests!

towards a federated bittorrent tracker with #sciop !

PR: https://codeberg.org/fediverse/fep/pulls/714

Discussion: https://socialhub.activitypub.rocks/t/fep-d8c8-bittorrent-torrent-objects/8309 (or this thread)

#FEP_d8c8 #BitTorrentOverActivityPub #FederatedP2P

The #FEP website built by @helge is now online:

https://fediverse.codeberg.page/fep/

Enjoy!

RE: https://mymath.rocks/objects/dad3deb4-a29d-4df3-a017-ae5700a387f3

The #FEP website built by @helge is now online:

https://fediverse.codeberg.page/fep/

Enjoy!

RE: https://mymath.rocks/objects/dad3deb4-a29d-4df3-a017-ae5700a387f3

The #FEP website built by @helge is now online:

https://fediverse.codeberg.page/fep/

Enjoy!

RE: https://mymath.rocks/objects/dad3deb4-a29d-4df3-a017-ae5700a387f3

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

https://codeberg.org/fediverse/fep/src/commit/e6f7b7ce32aa6f84dcfa7bfdc10fd65119d75984/fep/1580/fep-1580.md

https://codeberg.org/fediverse/fep/pulls/692

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

💡 Proposal for ActivityPub: FediStamp

What if any federated platform (Mastodon, WordPress, Pixelfed, PeerTube, WriteFreely...) could offer automatic certification of original content?

When publishing a poem, article, photo or video, you check "Certify original content" and the system gives you:

🔗 A public verifiable link to the registry

📄 A .fedistamp file as permanent proof

✅ A visible badge (Certified content) with clickable link

🧩 Metadata embedded in ActivityPub that travels with each share

Example: I publish a poem on Mastodon, enable the option, and instantly get my ✓ certified proof of authorship.

👉 This doesn't replace copyright (which already protects you), but strengthens it with technical evidence of authorship and date.

⚡ Key points:

Only registers the content hash (no cryptocurrency, just authorship certification).

Free.

Opt-in: you choose what to certify.

Automatic protection for creators across the federated ecosystem, without relying on centralized platforms.

I'm not a programmer, just a writer who sees the need. If someone technical sees merit and feasibility, go ahead.

#ActivityPub #Fediverse #FediStamp #FEP #ActivityPubDev #Mastodon #WordPress #Pixelfed #PeerTube #Creators #OpenSource #DigitalRights #OpenProposal

💡 Proposal for ActivityPub: FediStamp

What if any federated platform (Mastodon, WordPress, Pixelfed, PeerTube, WriteFreely...) could offer automatic certification of original content?

When publishing a poem, article, photo or video, you check "Certify original content" and the system gives you:

🔗 A public verifiable link to the registry

📄 A .fedistamp file as permanent proof

✅ A visible badge (Certified content) with clickable link

🧩 Metadata embedded in ActivityPub that travels with each share

Example: I publish a poem on Mastodon, enable the option, and instantly get my ✓ certified proof of authorship.

👉 This doesn't replace copyright (which already protects you), but strengthens it with technical evidence of authorship and date.

⚡ Key points:

Only registers the content hash (no cryptocurrency, just authorship certification).

Free.

Opt-in: you choose what to certify.

Automatic protection for creators across the federated ecosystem, without relying on centralized platforms.

I'm not a programmer, just a writer who sees the need. If someone technical sees merit and feasibility, go ahead.

#ActivityPub #Fediverse #FediStamp #FEP #ActivityPubDev #Mastodon #WordPress #Pixelfed #PeerTube #Creators #OpenSource #DigitalRights #OpenProposal

Any #GoToSocial developers, or anyone else who might know what the hold-up with publishing the FEP for reply controls is, interested in chiming in?

https://stefanbohacek.online/@stefan/115316306587338554

#fediverse #FEP #fedidevs #ReplyControls

https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0001.html

SocialCG people want to make their own FEP repository on GitHub where authors will be required to sign a CLA.

I'd like to make it clear: this is not associated with the original FEP repository. The #FEP process is meant to be open to everyone, and I will do everything I can to stop any attempts to introduce CLAs there.

https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0001.html

SocialCG people want to make their own FEP repository on GitHub where authors will be required to sign a CLA.

I'd like to make it clear: this is not associated with the original FEP repository. The #FEP process is meant to be open to everyone, and I will do everything I can to stop any attempts to introduce CLAs there.

https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0001.html

SocialCG people want to make their own FEP repository on GitHub where authors will be required to sign a CLA.

I'd like to make it clear: this is not associated with the original FEP repository. The #FEP process is meant to be open to everyone, and I will do everything I can to stop any attempts to introduce CLAs there.

[View Orginal URL] is a bug in the federation model.

https://spectra.video/w/72dbS6nFMwrgEtRb5h3Sk2

Great talk by @julian. Thank you!

#ActivityPub #FEP

[View Orginal URL] is a bug in the federation model.

https://spectra.video/w/72dbS6nFMwrgEtRb5h3Sk2

Great talk by @julian. Thank you!

#ActivityPub #FEP

FEP-9098: Custom emojis has been published.

#FEP #ActivityPub

FEP-9098: Custom emojis has been published.

#FEP #ActivityPub

FEP-9098: Custom emojis has been published.

#FEP #ActivityPub

FEP-9098: Custom emojis has been published.

#FEP #ActivityPub

Two upcoming changes in the #FEP process:

- Withdrawing stale proposals. If a proposal remains inactive for 2 years, its status is changed to WITHDRAWN. Previously, the period was 1 year after submission, and facilitators were supposed to contact authors before withdrawing (that didn't work well).
- Implementation tracking. If a proposal has type: implementation attribute, we will automatically count list items in the "Implementations" section and display that number somewhere (probably in README). If your proposal is implementable, I recommend adding type: implementation attribute to it. Also, don't forget to mention implementations if they exist - this information is very important.

Two upcoming changes in the #FEP process:

- Withdrawing stale proposals. If a proposal remains inactive for 2 years, its status is changed to WITHDRAWN. Previously, the period was 1 year after submission, and facilitators were supposed to contact authors before withdrawing (that didn't work well).
- Implementation tracking. If a proposal has type: implementation attribute, we will automatically count list items in the "Implementations" section and display that number somewhere (probably in README). If your proposal is implementable, I recommend adding type: implementation attribute to it. Also, don't forget to mention implementations if they exist - this information is very important.

Two upcoming changes in the #FEP process:

- Withdrawing stale proposals. If a proposal remains inactive for 2 years, its status is changed to WITHDRAWN. Previously, the period was 1 year after submission, and facilitators were supposed to contact authors before withdrawing (that didn't work well).
- Implementation tracking. If a proposal has type: implementation attribute, we will automatically count list items in the "Implementations" section and display that number somewhere (probably in README). If your proposal is implementable, I recommend adding type: implementation attribute to it. Also, don't forget to mention implementations if they exist - this information is very important.

»#PostQuantumPrivacy for #PostPlatformInternet. — #Fediverse pilots: #ActivityPub with #Dilithiumsignatures. While #Mastodon and other ActivityPub servers still use #RSA-#HTTP-#Signatures by default, developers in the #SocialHub community are working on a #FEP (Fediverse Enhancement Proposal) to clarify signature processing and accommodate #quantumsafealgorithms.« https://hackernoon.com/post-quantum-privacy-for-post-platform-internet?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News

FEP-521a: Representing actor's public keys has been finalized!

https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md

#fep #fep_521a

FEP-521a: Representing actor's public keys has been finalized!

https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md

#fep #fep_521a

FEP-844e: Capability discovery has been published to the FEP repository:

https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:

{
  "generator": {
    "type": "Application",
    "implements": [
      {
        "name": "RFC-9421: HTTP Message Signatures",
        "href": "https://datatracker.ietf.org/doc/html/rfc9421"
      }
    ]
  }
}

All important information is embedded, so additional HTTP requests are not necessary.

#FEP

FEP-844e: Capability discovery has been published to the FEP repository:

https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:

{
  "generator": {
    "type": "Application",
    "implements": [
      {
        "name": "RFC-9421: HTTP Message Signatures",
        "href": "https://datatracker.ietf.org/doc/html/rfc9421"
      }
    ]
  }
}

All important information is embedded, so additional HTTP requests are not necessary.

#FEP

FEP-844e: Capability discovery has been published to the FEP repository:

https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:

{
  "generator": {
    "type": "Application",
    "implements": [
      {
        "name": "RFC-9421: HTTP Message Signatures",
        "href": "https://datatracker.ietf.org/doc/html/rfc9421"
      }
    ]
  }
}

All important information is embedded, so additional HTTP requests are not necessary.

#FEP

FEP-844e: Capability discovery has been published to the FEP repository:

https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:

{
  "generator": {
    "type": "Application",
    "implements": [
      {
        "name": "RFC-9421: HTTP Message Signatures",
        "href": "https://datatracker.ietf.org/doc/html/rfc9421"
      }
    ]
  }
}

All important information is embedded, so additional HTTP requests are not necessary.

#FEP

FEP-844e: Capability discovery has been published to the FEP repository:

https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:

{
  "generator": {
    "type": "Application",
    "implements": [
      {
        "name": "RFC-9421: HTTP Message Signatures",
        "href": "https://datatracker.ietf.org/doc/html/rfc9421"
      }
    ]
  }
}

All important information is embedded, so additional HTTP requests are not necessary.

#FEP

I wrote a #FEP about actor statuses. Yeah, those things near the name that Facebook had in 2007.

https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md

#activitypub

I wrote a #FEP about actor statuses. Yeah, those things near the name that Facebook had in 2007.

https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md

#activitypub

I wrote a #FEP about actor statuses. Yeah, those things near the name that Facebook had in 2007.

https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md

#activitypub

Started writing a new FEP:

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Mentioned some best practices. What else should be added there?

#FEP #NodeInfo

Started writing a new FEP:

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Mentioned some best practices. What else should be added there?

#FEP #NodeInfo

Started writing a new FEP:

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Mentioned some best practices. What else should be added there?

#FEP #NodeInfo

Started writing a new FEP:

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Mentioned some best practices. What else should be added there?

#FEP #NodeInfo

Started writing a new FEP:

FEP-0151: NodeInfo in Fediverse Software (2025 edition)

Mentioned some best practices. What else should be added there?

#FEP #NodeInfo

As we consider ways to implement #ActivityPub into our FOSS Community Calendar Ecosystem platform Koalagator, I've been looking over the differing specs for how to specify the event object schema.

Have any other folk wrestled with this?Asking before I get arms deep in this stuff.

For those playing at home...

---
Schema.org - Event

Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet.

https://schema.org/Event

-----
W3C Activity Vocabulary - Event

This specification describes the Activity vocabulary. It is intended to be used in the context of the ActivityStreams 2.0 format and provides a foundational vocabulary for activity structures, and specific activity types.

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-event

----

Fediverse Enhancement Proposal
FEP-8a8e: A common approach to using the Event object type

ActivityStreams defines the Object Type Event. In real-world applications, the event object immediately showed the need for extension. Applications featuring Event objects have often chosen to add additional attributes and clarifications (i.e., interpretations) in order to implement their particular use case. This proposal clarifies and extends the ActivityPub standard to address the needs that have arisen in real-world implementations.

https://codeberg.org/linos/fep/src/branch/fep-8a8e/fep/8a8e/fep-8a8e.md

---

[HTML] Microformats - h-event

People are using microformats to mark up profiles, posts, events and other data on their personal sites, enabling developers to build applications which use this data in useful and interesting ways.

https://microformats.org/wiki/h-event

---

iCalendar Standard (RFC 5545)

iCalendar was first defined as a standard as RFC 2445 in 1998 by the Internet Engineering Task Force (IETF). Today, iCalendar is used to import and synchronize events on various platforms, including smart phones, computer and web applications.

https://icalendar.org/the-icalendar-standard-2.html

#EventObjectSchema
#Calendar #Standards #WebStandards #W3C #Microformats #FEP #FediverseEnhancementProposals #iCal #iCalendar #FOSS #WebDevelopment #WebDesign #RubyOnRails #Rails #Mastodon #Dev #Developer #OpenStandards

I am working on a new revision of FEP-8b32:

https://codeberg.org/fediverse/fep/pulls/527

There are many editorial changes, such as replacing Controller Documents with Controlled Identifiers, new implementation (apsig), and one new requirement:

>The identifier of the verification method MUST have the same origin as the identifier of the secured document, or have a different origin, but with an established cross-origin trust relationship to the identifier of the secured document.

This is related to today's FEP-fe34 update and should cover all possible uses of integrity proofs, including regular objects signed with DID keys, and portable objects (FEP-ef61). I expect that all existing implementations of FEP-8b32 already meet this new requirement, but if not, please let me know. I'll keep this PR open / WIP for a couple of days.

#fep_8b32 #fep

FEP-fe34 "Origin-based security model" has been updated:

https://codeberg.org/fediverse/fep/pulls/526

There is a new section discussing cross-origin relationships. Some use cases require bypassing of same-origin policy, and in such situations confirmations of both authorities are required. One interesting example is FEP-c390: Identity Proofs, where trust is established by verification of complementary claims made by an HTTP authority (actor document) and DID authority (identity proof document).

I also added the definition of "authentication":

>Authentication is the process of verifying the origin of an object.

And the definition of "authorization":

>Authorization is the process of verfying permission to create, read, update or delete an object.

#fep_fe34 #fep

FEP-fe34 "Origin-based security model" has been updated:

https://codeberg.org/fediverse/fep/pulls/526

There is a new section discussing cross-origin relationships. Some use cases require bypassing of same-origin policy, and in such situations confirmations of both authorities are required. One interesting example is FEP-c390: Identity Proofs, where trust is established by verification of complementary claims made by an HTTP authority (actor document) and DID authority (identity proof document).

I also added the definition of "authentication":

>Authentication is the process of verifying the origin of an object.

And the definition of "authorization":

>Authorization is the process of verfying permission to create, read, update or delete an object.

#fep_fe34 #fep

I am working on a new revision of FEP-8b32:

https://codeberg.org/fediverse/fep/pulls/527

There are many editorial changes, such as replacing Controller Documents with Controlled Identifiers, new implementation (apsig), and one new requirement:

>The identifier of the verification method MUST have the same origin as the identifier of the secured document, or have a different origin, but with an established cross-origin trust relationship to the identifier of the secured document.

This is related to today's FEP-fe34 update and should cover all possible uses of integrity proofs, including regular objects signed with DID keys, and portable objects (FEP-ef61). I expect that all existing implementations of FEP-8b32 already meet this new requirement, but if not, please let me know. I'll keep this PR open / WIP for a couple of days.

#fep_8b32 #fep

I am working on a new revision of FEP-8b32:

https://codeberg.org/fediverse/fep/pulls/527

There are many editorial changes, such as replacing Controller Documents with Controlled Identifiers, new implementation (apsig), and one new requirement:

>The identifier of the verification method MUST have the same origin as the identifier of the secured document, or have a different origin, but with an established cross-origin trust relationship to the identifier of the secured document.

This is related to today's FEP-fe34 update and should cover all possible uses of integrity proofs, including regular objects signed with DID keys, and portable objects (FEP-ef61). I expect that all existing implementations of FEP-8b32 already meet this new requirement, but if not, please let me know. I'll keep this PR open / WIP for a couple of days.

#fep_8b32 #fep

FEP-fe34 "Origin-based security model" has been updated:

https://codeberg.org/fediverse/fep/pulls/526

There is a new section discussing cross-origin relationships. Some use cases require bypassing of same-origin policy, and in such situations confirmations of both authorities are required. One interesting example is FEP-c390: Identity Proofs, where trust is established by verification of complementary claims made by an HTTP authority (actor document) and DID authority (identity proof document).

I also added the definition of "authentication":

>Authentication is the process of verifying the origin of an object.

And the definition of "authorization":

>Authorization is the process of verfying permission to create, read, update or delete an object.

#fep_fe34 #fep

Our latest #PushingTheBoundaries online discussion is out!

Check it out at:
https://youtu.be/0zeIlfv5srg

We talk to Kate Nave about her book "A Drive To Survive."

https://mitpress.mit.edu/9780262551328/a-drive-to-survive

Bioenactivism and why the free-energy principle (#FEP) does not explain life.

Our latest #PushingTheBoundaries online discussion is out!

Check it out at:
https://youtu.be/0zeIlfv5srg

We talk to Kate Nave about her book "A Drive To Survive."

https://mitpress.mit.edu/9780262551328/a-drive-to-survive

Bioenactivism and why the free-energy principle (#FEP) does not explain life.

Updating "FEP-f06f: Object observers": https://codeberg.org/fediverse/fep/pulls/512

I was thinking about managing a thread with #ActivityPub client and realized that observer actors would need to be created with Create(Application) activity where actor is user's primary actor (the one created during the registration).

This is unusual, but should work. Primary actors can't be created this way because the actor property of Create activity can't refer to a not yet created actor.

#fep #fep_f06f

Updating "FEP-f06f: Object observers": https://codeberg.org/fediverse/fep/pulls/512

I was thinking about managing a thread with #ActivityPub client and realized that observer actors would need to be created with Create(Application) activity where actor is user's primary actor (the one created during the registration).

This is unusual, but should work. Primary actors can't be created this way because the actor property of Create activity can't refer to a not yet created actor.

#fep #fep_f06f

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

All implementations of FEP-521a are implementations of Controlled Identifiers spec.

#fep #fep_521a #ActivityPub #ControlledIdentifiers

RE: https://w3c.social/users/w3c/statuses/113947371169653222

All implementations of FEP-521a are implementations of Controlled Identifiers spec.

#fep #fep_521a #ActivityPub #ControlledIdentifiers

RE: https://w3c.social/users/w3c/statuses/113947371169653222

All implementations of FEP-521a are implementations of Controlled Identifiers spec.

#fep #fep_521a #ActivityPub #ControlledIdentifiers

RE: https://w3c.social/users/w3c/statuses/113947371169653222

FEP-2277: ActivityPub core types has been submitted to the FEP repository.

I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.

Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.

#FEP #ActivityPub

FEP-2277: ActivityPub core types has been submitted to the FEP repository.

I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.

Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.

#FEP #ActivityPub

FEP-2277: ActivityPub core types has been submitted to the FEP repository.

I made several changes based on the feedback, but they are minor. There are parallel discussions at W3C GitHub, where I was told that core types don't exist, or don't matter, but this is obviously wrong, because many requirements in AP and AS depend on definitions of "collection", "activity" and other core types. Classification of objects based on their properties still seems to be the best solution.

Also, due to an uncertainty about the future of SocialHub (where many accounts are going to be suspended soon), I didn't create a discussion topic there. If you have any suggestions or feedback, please reply here or open an issue at https://codeberg.org/silverpill/feps/issues.

#FEP #ActivityPub

I've made some changes to FEP-521a: https://codeberg.org/fediverse/fep/pulls/482

- Many changes due to a rename of Controller Documents specification to Controlled Identifiers.
- Using https://www.w3.org/ns/cid/v1 context in example. I haven't tried it myself yet, but it works in JSON-LD playground.
- Key ID and actor ID are now recommended to have same origin.

#fep_521a #fep

I've made some changes to FEP-521a: https://codeberg.org/fediverse/fep/pulls/482

- Many changes due to a rename of Controller Documents specification to Controlled Identifiers.
- Using https://www.w3.org/ns/cid/v1 context in example. I haven't tried it myself yet, but it works in JSON-LD playground.
- Key ID and actor ID are now recommended to have same origin.

#fep_521a #fep

I've made some changes to FEP-521a: https://codeberg.org/fediverse/fep/pulls/482

- Many changes due to a rename of Controller Documents specification to Controlled Identifiers.
- Using https://www.w3.org/ns/cid/v1 context in example. I haven't tried it myself yet, but it works in JSON-LD playground.
- Key ID and actor ID are now recommended to have same origin.

#fep_521a #fep

FEP-2277: ActivityPub core types (pre-draft)

https://codeberg.org/silverpill/feps/src/branch/main/2277/fep-2277.md

where I make a case for non-overlapping core types and duck typing

#ActivityPub #FEP

FEP-2277: ActivityPub core types (pre-draft)

https://codeberg.org/silverpill/feps/src/branch/main/2277/fep-2277.md

where I make a case for non-overlapping core types and duck typing

#ActivityPub #FEP

FEP-2277: ActivityPub core types (pre-draft)

https://codeberg.org/silverpill/feps/src/branch/main/2277/fep-2277.md

where I make a case for non-overlapping core types and duck typing

#ActivityPub #FEP

FEP-2277: ActivityPub core types (pre-draft)

https://codeberg.org/silverpill/feps/src/branch/main/2277/fep-2277.md

where I make a case for non-overlapping core types and duck typing

#ActivityPub #FEP

FEP-9967: Polls

https://codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md

#activitypub #fep

FEP-9967: Polls

https://codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md

#activitypub #fep

FEP-9967: Polls

https://codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md

#activitypub #fep

FEP-9967: Polls

https://codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md

#activitypub #fep

Working on polls and writing a new #FEP

https://codeberg.org/silverpill/feps/src/branch/main/9967/fep-9967.md

Working on polls and writing a new #FEP

https://codeberg.org/silverpill/feps/src/branch/main/9967/fep-9967.md

Working on polls and writing a new #FEP

https://codeberg.org/silverpill/feps/src/branch/main/9967/fep-9967.md

FEP-67ff: FEDERATION.md has been finalized.

It is now supported by 17 Fediverse projects!

#fep

"FEP-171b: Conversation Containers" finally has been published:

https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md

Conversation Containers are conceptually very similar to FEP-1b12: activities are sent to a conversation owner, who manages the conversation and synchronizes it between participants. Differences are mostly superficial and may disappear in the future.

#FEP #ConversationContainers #ActivityPub

FEP-fe34: Origin-based security model has been published. It supersedes FEP-c7d3: Ownership and describes authentication of ActivityPub objects in simpler terms.
I think ownership is still useful for authorization and access control, so that part was copied from FEP-c7d3.

#fep #activitypub

@forteller

yes, this is a pain. What you are describing is basically a "quote post" which mastodon does not support.

There are other services that do support via #fep-e232

https://codeberg.org/fediverse/fep/src/branch/main/fep/e232/fep-e232.md

FEP-c7d3 had a major update: https://codeberg.org/fediverse/fep/pulls/387

Now it covers all aspects of ownership, including ownership transfer, and provides a comprehensive authentication and authorization framework for ActivityPub implementers.

#fep

FEP-c0e0: Emoji reactions

https://codeberg.org/fediverse/fep/src/branch/main/fep/c0e0/fep-c0e0.md

>This document describes how emoji reactions are implemented in ActivityPub network.

#fep

Hey folks into #ActivityPub and #p2p / #dweb tech. We've got a new #FEP in the works to bridge between the two worlds based on the work we've been doing at @distributed

Come check it out and let us know what you think and if you'd like to implement it yourselves!

https://codeberg.org/fediverse/fep/pulls/379

i woke up today thinking about something thats been bothering me a lot about :butterfedy1: :butterfedy2: :butterfedy3: fedi, the timeline, it gets drowned by ultra shortform discussions, i dont want to mute anyone because many discussions are great, but i just want something that rotates through everyone i follow in a given time period, eg "give me one post from everyone in the past 6 hours".

the difficulty is coming up with a good "interval time" ie. what if the last "hour" is the most important or, "2 hours" or past "day" ....how to pick this meaningful intervalTime. i'm still in bed thinking about this. Then i realize that the interval time is WHATEVER MY AVERAGE POSTING RATE IS over the day. So if in the past 24 hours I post 1 post per 4 hours then the intervalTime ought be 4 hours. So give me one post from everyone i follow in the past 4 hours.... after that is exhausted? 8 hours, so excluding the posts already shown, cycle through every person i follow who has posted in the past 8 hours, then 12 etc

this way, when i return to :butterfedyC: #fediverse after a break, i can quickly see the latest from everyone i follow, but as i post on :butterfedyA: fedi the interval time will shorten and i'll see things in a more compressed timeframe. The key is to get these intervals right.... maybe 1day.... POST.... 15hrs.... POST.... 9hr POST.... 5 POST.... 3hrs this seems like a good way to go.... after 4 posts the interval is down to 3hrs???

i dont believe likes should affect the intervalTime, boosts maybe can be taken as if the booster made that toot at that time, so if the post ur boosting is from 2 years ago, then it doesn't affect intervaltime.

do you like this idea? what to call this sort of timeline....? Rotary....? Rounded? Cyclic.......??? who knows but i def think i'd benefita lot from a timeline like this.

#fedimeta #fep