silverpill

@evan

I think the cost of my audit will be at least half of what @sovtechfund 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

@sun @harblinger #LetsPokeTheBear

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

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

@greyarea 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.

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

@phnt Maybe somebody made a hello world dot js but none of these implementations reached production readiness. And if you look at what they are talking about today at github.com/w3c, it's exactly as you said, everyone pretends that nothing has happened since 2018.

@phnt

>member of the committee overseeing the protocol does not care about implementing any extension made in the last decade

Are you talking about ActivityPub?

@harblinger

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?

If you prefer catalogs to be created by a server, then I would add this sentence to section "Catalog":

The emoji catalog MUST be represented as an Activity Streams Collection, which contains FEP-9098 Emoji objects. The server creates this collection when an actor is registered.

These sentences could be added to the "Updates" section:

Adding an emoji to an actor-specific catalog means that the emoji is available for use by that actor in newly created content. Emojis are added using Add activities where the target is an emoji catalog.

Removing an emoji from an actor-specific catalog means that the emoji is no longer available for use by that actor in newly created content. Emojis are removed using Remove activities where the target is an emoji catalog.

Examples of Add and Remove activities could be added as well.

-----

@boiert I prefer specific activities (AddEmoji), rather than generic operations (Add), but that's a discussion for another thread.

@graf No, I only have a monero wallet (for opsec reasons). But if you have other coins you can send them via Trocador, for example: link.

@k4t3 Microsoft and Gitlab are probably celebrating right now. I hope forge federation will come soon enough

@DoomHammerNG It is a work in progress. Forgejo has federated stars and some other things, I can't tell much because I haven't tried it myself yet.

You can find their roadmap at https://codeberg.org/forgejo-contrib/federation

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

@pds.dad We have signatures that are embedded in activities (FEP-8b32). Not all AP software uses them, though. There are also decentralized identity schemes that rely on these embedded signatures

There are at least 3 ways to update a collection:

- Add, Remove and Move activities.
- Update activity.
- Side effect of another activity (for example, AddEmoji).

Similarly, there are many ways to create a collection. Creating a collection during the registration of an actor is a valid option, but it is not the only one.

Other important details: addressing, authorization.

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.

ActivityPub doesn't explain how collections are created or updated (it only mentions side effects of certain activities that affect collections). You can skip all of that and state that emoji catalog is server-managed. However, in that case the sentence "A standardized emoji catalog allows a C2S client to" wouldn't make sense.

@harblinger

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.

@greyarea

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/