Boosted by @dansup@mastodon.social
I finally created a #FEP for using #CreativeCommons licenses (and other licenses) in #ActivityPub.
https://codeberg.org/fediverse/fep/pulls/939
#fep
18 posts · Last used 6d
Boosted by @dansup@mastodon.social
Pixelfed has never federated Blocks, which can cause some issues, so we came up with a Block Synchronization FEP that is heavily inspired by the Mastodon Follower Collection Sync FEP!
Blocks will soon federate, and Pixelfed will be the first implementation to support this Block Sync FEP.
PR: https://github.com/pixelfed/pixelfed/pull/7583
#pixelfed #blockSynchronization #activitypub #fep
Wrote and submitted my first FEP!
FEP-070c: Block synchronization across servers
Just wrapping up the implementation in Pixelfed as we speak.
https://github.com/pixelfed/pixelfed/pull/7583
#pixelfed #blockSync #fep #activityPub
Replying to
@berlinfediday@berlin.social @julian@fietkau.social I did not know about SciOp.
Great project and they are making a #FEP (https://fediverse.codeberg.page/fep/fep/d8c8/) to allow #BitTorrent data types in #activitypub - cool!
#FEPd8c8
Boosted by @fedicat@pc.cafe
<p>Hm... <a href="https://w3id.org/fep/c0e0" rel="nofollow ugc">FEP-c0e0: Emoji reactions</a> details two ways to federate an Emoji reaction:</p> <ol> <li><code>EmojiReact</code> activity</li> <li><code>Like</code> with <code>content</code> (as opposed to a regular <code>Like</code>, which has no content)</li> </ol> <p>In testing, I noticed that misskey (or at least, the site I was testing with, <code>birb.space</code>) sends the latter. I don't know what sends the former, and if NodeBB were to start federating out <code>EmojiReact</code>, would it be broadly understood?</p> <p>Perhaps I should federate out both at once.</p> <p>cc <a href="https://mitra.social/users/silverpill">@<bdi>silverpill@mitra.social</bdi></a></p>
<p>This is the main discussion thread for the draft FEP-c0d0: Context Locking</p> <h2>Summary</h2> <p>Context locking (and its inverse, unlocking) refer to the action whereby a topic no longer accepts new replies.</p> <p>This proposal introduces a <code>locked</code> property on the context object, and a new activity type, <code>Lock</code>, to signal changes to a topic's locked state across the fediverse. Unlocking is expressed with the standard ActivityStreams <a href="https://www.w3.org/TR/activitystreams-core/#activity-undo" rel="nofollow ugc"><code>Undo</code> activity</a>, applied to the original <code>Lock</code>. [...]</p>
Boosted by @fedicat@pc.cafe
We've introduced a new metadata field for FEPs: tags
https://codeberg.org/fediverse/fep/pulls/885
Tags are free-form and should be specified as a YAML array:
tags: ["groups", "permissions"]
#fep
Since @evan@cosocial.ca seems unable (or unwilling) to understand that many users desire the #FediVerse to be a place where opt-in is the normal and expected implementation for features such as #relays I propose that #fedidevelopers take up this call.
The problem: the implementation of relays lacks sufficient user-based controls. While users may (at least on platforms such as GotoSocial) add relays they desire to have their content sent to, there are no user based controls over relays configured at the instance level.
The current implementation appears to have unintended, and unconsidered consequences associated with it.
Ban evasion can likely be achieved through chaining relays together. We have already seen the unintended consequence of a relay following tags.pub leading to content being relayed non-consensually.
Something that has not been considered is potential damages to users in regions where political, social, or religious beliefs are sensitive topics need to maintain tight controls over where their content is sent. This is a case where the handling and relaying of posts needs to be 100 percent bulletproof.
The Solution: all platforms in the Fediverse should implement instance level relays in the following manner:
Instance level relays are disabled for all users on that instance.User settings provide a list of the relays provided at the instance level.Users can opt to leave the relay(s) disabled, orThey can choose to enable the relays they trust their content being sent to.
Through this implementation we avoid clunky workarounds like adding hashtags to profiles. Also, we make this feature more discoverable for new users who are unfamiliar with the conventions of the FediVerse.
I am unfamiliar with the #FEP submission process and requirements. Anyone willing to work with me on this, I would like to see this brought forth as a FEP.
#fedideveloperverse #fedideveloper #mastodon #gotosocial #misskeyworld #misskey #pixelfed #microdotblog #pleroma #sharkeydev
@alice@lgbtqia.space @admin@gotosocial.social @gotosocial@gts.superseriousbusiness.org @Gargron@mastodon.social
Trying to see where things are with FEP-ef61: Portable Objects. Anyone working on this?
https://fediverse.codeberg.page/fep/fep/ef61/
https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738
#fediverse #FEP #PortableObjects #FEPEF61
Boosted by @fedicat@pc.cafe
FEP-5219: Groups and permissions has been added to the FEP repository.
#fep #fep_5219
RE: https://mitra.social/objects/019e87e9-62a6-71d1-8edc-3a8a63e96c9f
Boosted by @fedicat@pc.cafe
FEP-f228: Backfilling conversations has been updated:
https://codeberg.org/fediverse/fep/pulls/853
I added tootik and Lemmy to the implementation list and did a little cleanup. This FEP feels complete, so I am requesting final comments.
Full text:
https://fediverse.codeberg.page/fep/fep/f228/
#fep_f228 #fep #fedidev
Hey @mariusor@metalhead.club,
we are looking into your #Go #Activitypub library to implement federation in #LAUTI
One thing we need to do is implement the #FEP 8a8e by @linos@graz.social
Do you have time for a quick call to get an overview?
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.
Replying to
cc @evan@cosocial.ca relating to earlier #TagsPub discussion we had on the matter.
This bot is already combining logic, has multiple 'profle logic' tags. Dunno if "NoBots" is also already common protocol-decaying practice.
Maybe a solution might be that an #ActivityPub bot actor - OT: which I'd personally perhaps had chosen to be Application, not Service actors - would have a botFlags property. Simple to implement, and #FEP that.
More involved but also much more versatile might be a "Botiquette" as:Profile, or even a bots:Botiquette type, and a namespace to register them at, and where others may find what they mean and how they operate exactly.
#NoBots #nobot #fedi22 #NoTagsPub #Botiquette
Arnold Schrijver (@smallcircles@social.coop) 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 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
You've seen all posts