silverpill

@katzenmann@c3d2.social The best part is that we have relays too. They can even be big, like in ATProto world - but they are not indispensable, just additional services that improve discovery.

@darkcat09@gts.dc09.xyz @grishka@mastodon.social @mariusor@metalhead.club I still don't give a fuck, the FEP is about public keys. But there is a note in "Security considerations": https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md#security-considerations

FEP-0806: Simple client-side encryption https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md The FEP now includes the recommended algorithm parameters. I consider it finished but I don't plan to continue working on my implementation or publishing to the main FEP repository. It would be better to focus on group messaging with forward secrecy (MLS or similar). #fep_0806 #e2ee

@greyarea@mitra.vpclmulqdq.moe I added HPKE algorithm parameters to the FEP: https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md#algorithms KEM: DHKEM(X25519, HKDF-SHA256) AEAD: ChaCha20Poly1305 KDF: HKDF-SHA256 "info" string: fep-0806-info "aad" string: fep-0806-aad Does it look right? KEM/AEAD/KDF choices are not my preferences, I just copied them from another HPKE+ed25519 implementation.

@harblinger@wizard.casa so under a week's usage allocation for the lowest cost $20/mo tier Not bad. I guess it will get even cheaper in the future codex cli Is there any difference between all those coding agents?

Setting up a Forgejo instance: https://code.mitra.social/silverpill/mitra It will be mirroring repositories related to the #Mitra project. I don't plan to migrate from Codeberg right now, but it wouldn't hurt to have a self-hosted instance in case they decide to enforce the new anti-crypto policy. This will also allow me to test the implementation of federation in Forgejo.

@harblinger@wizard.casa I would find that offensive

I finally got around to trying #iroh It nicely complements FEP-ef61, because it allows you to connect to another actor by its did:key. In theory, we can completely replace the federation of HTTP servers with a federation of iroh nodes. However, I'm not convinced that iroh is the best solution. The most obvious problem is a lack of anonymity. Newer versions of iroh support custom transports, and Tor transport is among them, though still experimental. The work on I2P transport has not started yet. Another problem is the requirement to be online all the time. A potential solution is iroh-gossip, which I haven't tried yet, but I doubt that it works good enough for nodes that come online once per week. A more traditional approach to FEP-ef61 with a combination for clearnet, tor and i2p gateways might be simpler and better. But iroh is an interesting project that's worth keeping an eye on. https://codeberg.org/silverpill/minimitra/src/commit/2dd4e4f82b476f6b0a3d2610f158691ad5f46d11/src/p2p_iroh.rs

@julian @z9mb1@hackers.pub There are already two Rust frameworks... Also some parts of the code look very familiar to me, which is not surprising given that the project is vibe coded (= plagiarized). @iftas@mastodon.iftas.org @smallcircles@social.coop

@greyarea@mitra.vpclmulqdq.moe

I can think of two scenarios where HPKE-level sender authentication or aad binding might be important:

1. The sender creates an activity that is attributed to somebody else, encrypts it, and sends to the recipient. This shouldn't be a problem, because the inner activity MUST be portable, and therefore required to have an integrity proof. A compliant recipient can't be fooled into thinking that misattributed activity is real.
2. Somebody (e.g. server operator) takes the fep0806:cipherText out of EncryptedActivity, and creates a new activity with the same fep0806:cipherText but different id, actor and/or to. This shouldn't be a problem either. In the worst case, the activity will be delivered to somebody else who will not be able to decrypt it. Replacing id and actor may be even a good thing (obfuscation).

it was a giant mess of w3c specs.

It's an ever-expanding mess of W3C specs, RFCs and FEPs.

Integrity proofs are relatively new, they are described in Data Integrity W3C spec: https://www.w3.org/TR/vc-data-integrity/

@doesnm @harblinger@wizard.casa Julia 1 is exactly what I had in mind. Gonna give it a try. Thanks!

@grishka@mastodon.social @mariusor@metalhead.club Sorry for the trouble :) The expectation was that developers will use a library for base58-btc (and maybe for multicodecs too).

I think there should be a "Prior art" or "History" section.

The biggest problem for peer to peer ActivityPub is the fact that ActivityPub is primarily a "pull" protocol. You need to fetch a remote actor before interacting with it. This is not feasible in the environment where nodes are intermittently online. What if we used a special activity to request objects? I've described this idea in more detail in Asynchronous object retrieval: https://codeberg.org/silverpill/feps/src/branch/main/aef6/fep-aef6.md I think this mechanism, if combined with self-authenticating objects, should make ActivityPub compatible with store and forward protocols. #p2p #dtn #fep_ef61

@heluecht inaccurate representation vs lost signal I think the former is better for the majority of users. You can also make it an admin setting or even an account setting. @liaizon@social.wake.st

@pernia@cum.salon @meso@new.asbestos.cafe I haven't used this nginx config for a long time but the regex looks correct. Maybe there is clash between mitra and chanfe paths? @harblinger@wizard.casa

Updating FEP-5219: Groups and permissions: https://codeberg.org/fediverse/fep/pulls/944/files I've introduced a new property, audiences, which lets you define collections containing actors with a specific role / privilege / affiliation: { "id": "https://social.example/group", "type": "Group", "audiences": { "admin": "https://social.example/group/admins", "moderator": "https://social.example/group/moderators", "member": "https://social.example/group/members" } } For example, you can use such collection to address an activity to group admins. These collections are also needed for interactionPolicy declarations, which has appeared in some proposals related to private groups. #fep_5219

@greyarea@mitra.vpclmulqdq.moe >If the proof covers all of that then it's not strictly needed, but it's cheap paranoia. Do you mean id/actor/to of a plaintext activity, or of an envelope (EncryptedActivity)? My understanding is that the properties of an envelope have no effect on security. It can even have a different actor. I added an example of a plaintext activity: https://codeberg.org/silverpill/feps/src/branch/main/0806/fep-0806.md#plaintext-activity Also added HPKE mode to the parameter list - mode_base.

@reverend@social.undeadnetwork.de Sounds like they started rolling out FASPs https://github.com/mastodon/fediverse_auxiliary_service_provider_specifications

The ap-next developer guide was removed from the https://activitypub.rocks website: https://github.com/swicg/activitypub.rocks/issues/63 (by the father of the Fediverse, no less). The reason: It's a fork outside the SocialCG. This is utter nonsense. The guide refers to the original ActivityPub specification and even to SocialCG reports covering Webfinger and HTTP signatures. The other ap-next project is NomadPub - a collection of FEPs that significantly expand the capabilities of the protocol but don't diverge from the original spec. However, since dissenting opinions about the present and the future of ActivityPub are now openly censored, a fork may indeed be necessary.

FEP-171b has been updated: https://codeberg.org/fediverse/fep/pulls/931 The document now mentions canReply property which is used in reference implementations (Streams and Forte). { "type": "Note", "canReply": ["https://alice.example/followers"], ... } #fep_171b #ConversationContainers

@evan@cosocial.ca I think the cost of my audit will be at least half of what @sovtechfund@mastodon.social offered for this work (€246,521.00): https://www.sovereign.tech/tech/activity-pub In XMR, of course. At the current rate, it's 418 XMR. Special offer! 399.9 XMR until the end of July. @greyarea@mitra.vpclmulqdq.moe

@harblinger@wizard.casa >>>reply tagging What do you think about federating these as quotes? Mitra supports multiple quotes per post (imageboard use case was taken into consideration when the feature was developed). >>>(Cross-thread) markdown copy and quote posting If you use the [[]] microsyntax, the link will be parsed as a quote: [[https://wizard.casa/objects/019fc0a1-a9ef-7731-997e-40dd6864f469|>>1234567]]

What other AP frameworks do you know of? This one is used in Mitra and all my other projects: https://docs.rs/apx_sdk/latest/apx_sdk/ There are many libraries, actually - the Delightful List has already been mentioned in this thread. But most of these libraries are not actively developed, or not used in any serious project. So I've been thinking of adding a curated list of libraries to the ActivityPub developer guide.

Private groups Lately, I've been seeing various people claiming that fediverse doesn't have private groups. They often point to some task force at w3c that is supposedly working to fill the gap.

However, fediverse has had private groups for a very long time:

• Hubzilla channels. This project probably had private groups before ActivityPub. The implementation was later adapted for ActivityPub and refined in subsequent forks, Streams and Forte. It is now partially documented in FEP-171b: Conversation Containers.
• Smithereen groups. This implementation is documented in FEP-400e: Publicly-appendable ActivityPub collections (published in 2021) and FEP-db0e: Authentication mechanism for non-public groups.
• Lemmy communities. Private groups were proposed in Lemmy RFC 0005 and have been implemented in the development version. There is a test instance running this version (Lemmy v1.0b) at https://voyager.lemmy.ml/

There are probably other implementations that I am not aware of.

#Hubzilla #Smithereen #Lemmy

@harblinger@wizard.casa Let's do it on 'berg, I think it's going to be alright. My instance currently works only as a mirror.

@phnt@fluffytail.org @i@declin.eu @p@fsebugoutzone.org @lain@lain.com @jaff@mk.magicka.org @cjd@pkteerium.xyz @mint@ryona.agency @sun@shitposter.world @rees@tsundere.love Your other option is Njalla with TOS that says updating your server behind the domain is against TOS. Whaaat? I use Njalla btw.

EmojiReact is used by Pleroma. Idk about others, I started with EmojiReact but then switched to Like - Mastodon users can see a "favorite" that way.

We also explicitly do not tolerate: ... Content that harms the reputation of Codeberg, such as cryptocurrency related projects. That's particularly funny. Nothing harms your reputation as much as policies inspired by stupid ragebait like web3isgoinggreat.com

@julian Regular users don't know what software supports reactions and what software is installed on a remote server. They click on an emoji but the reaction never reaches the other side. @heluecht @liaizon@social.wake.st

@julian @skavish@welley.social Yes, an FEP can cover a non-technical topic too.

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

@harblinger@wizard.casa Did you use the free version to debug counters?

@evan@cosocial.ca @greyarea@mitra.vpclmulqdq.moe Yes, but I don't like it. The specification is incomplete and has some serious flaws.

@harblinger@wizard.casa It looks really interesting. Is there something similar that you can run locally?

@harblinger@wizard.casa I haven't and their website makes me want to close the tab https://astro.build

@julian@fietkau.social @julian the context-level interaction controls This is documented in FEP-171b: Conversation Containers. @technical-discussion

@greyarea@mitra.vpclmulqdq.moe having the sender generate an ephemeral keypair (include the public key envelope) So the recipient will need to encrypt to this ephemeral key when replying?

@meso@new.asbestos.cafe @pernia@cum.salon Yes, take a look at this nginx config: https://codeberg.org/silverpill/mitra/src/branch/main/contrib/nginx/mitra-alt-fe.conf#L46 It's better to serve mitra-web with mitra though, because it adds some useful redirects.

@julian Parts of FEP-5219 are implemented in Mitra. You could be the next implementer :D It's not really ready though, I am still collecting feedback from developers that need fine-grained permissions. We need a system that works for them as well as for simple forums where two roles is enough (user and admin). @Profpatsch@mastodon.xyz

I added a list of recommended libraries to the ActivityPub developer guide:

https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#libraries

• activity (Go, used in GoToSocial)
• Fedify (JavaScript, used in Hollo and Ghost)
• Fedipub (Ruby, used in Manyfold)
• activitypub_federation (Rust, used in Lemmy)
• APx (Rust, used in Mitra)

This list only includes libraries that are actually used somewhere. Libraries that are not used, or used in projects with too few users are not included.

#fedidev #activitypub

Proposal: Replace gateways query parameter in 'ap' URIs with @gateway, which can be used multiple times https://codeberg.org/fediverse/fep/pulls/890 Before: ?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example After: ?@gateway=https%3A%2F%2Fserver1.example&@gateway=https%3A%2F%2Fserver2.example Query parameters are often used to specify collection filters. The @ prefix will make it clear that gateway parameter is special. #fep_ef61

@caohuak@moon.lonewolf.zone No, this path leads to capability negotiation hell.

@julian So why does 8b32 allow for dropping the HTTP signature? My best guess is that the wording is vague and the intention is that an object integrity proof at top level means an HTTP signature can be discarded. You're right, the sentence was poorly written. It was meant to apply to top-level proofs only. I'll update the FEP. I know of no situation where an AP-compliant server POSTs another server without an HTTP Signature. Pretty sure any attempt to do so would just mean the activity is dropped. Mitra would accept an activity with integrity proof if HTTP signature is not present.

@greyarea@mitra.vpclmulqdq.moe Thanks a lot for reviewing it. Now that I understand the basics, it's time to explore more complex schemes with perfect forward secrecy. I'll probably start with MLS and its "decentralized" variants.

@greyarea@mitra.vpclmulqdq.moe I assume this is "Authentication Using an Asymmetric Key" (https://www.rfc-editor.org/rfc/rfc9180.html#name-authentication-using-an-asy) Because in "Encryption to a Public Key" mode, sender's key is not used. If I understand the idea correctly, the ephemeral key would need to be added to fep0806:cipherData. That is, instead of encap_key | ciphertext it will be ephemeral_key_pub | encap_key | ciphertext.

@reverend@social.undeadnetwork.de For those of us who don't use Mastodon, what is this "Discovery"?

@harblinger@wizard.casa It's not bad! Creating a sibling to get_direct_conversations is a good idea. >2. What Mitra already has >The missing piece is only that nothing orders conversations by activity, and nothing exposes them at public visibility. This is correct. However, I think the results of get_direct_conversations can be ordered by activity (post.created_at). I made a quick test, the estimated cost of the query is exactly the same. >3.1 A bump column on conversation ...So this shouldn't be necessary. >Three details worth deciding deliberately: >Reposts have no conversation_id I've never seen an imageboard with reposts. I think only comments should bump threads. >Only public activity should bump a public thread. If the cost is not too high, we can bump threads on private comments too. get_direct_conversations already does that. >3.2 The endpoint I think /api/v1/conversations is a better prefix for the endpoint. >root_status — the OP; this is the catalog card. The query already joins post AS root, it just doesn't return it today. >last_status — newest activity, already produced by the lateral. Its id doubles as the max_id for the next page. Returning whole Status is expensive. Unless you need to know everything about both root_status and last_status, I recommend returning a partial entity (e.g. only a title of the root). >3.3 Optional: the same for group timelines >Strictly a follow-up. 👍 This should be delayed until private groups are implemented.

@harblinger@wizard.casa True, I'm going to re-skin AP 'repost' as 'bump' eventually. Good AP primitive to fix the no-signal bump posts common on image boards (picrel). That's an interesting idea. Maybe reposts should be tied to conversations, but let's keep this focused on comment-bumps for now. Just implemented mitra subs recently too :) 🔥 Filtering private comments is to prevent users not in the convo being confused by what appears to be no activity bumped threads. You can pass the current user to the query... But no need to make it more complicated than necessary. I hope it's not annoying slop, let me know if you want me to run any further tests Stored conversation.last_activity_id with a btree index Premature optimization. It's never too late to add extra column. Endpoint prefix. /api/v1/conversations is fine. The only wrinkle is that the bare path is Mastodon's DM conversation list, which Mitra already serves, so the public one likely wants to be a sibling path — /api/v1/conversations/public or similar. Yes, we should use /api/v1/conversations/public slop slop slop Do you intend to send a patch?