silverpill

@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/

The collections would be created by the server with no user/external input, it should just exist - the way outboxes "exist"

I suggest adding this requirement to the FEP. Some server implementations don't contain application-specific logic, and only support explicit creation of collections.

Using standard AP C2S?

Not necessarily. Any kind of C2S that results in activities being added to outbox.

Create for new emojis, Add to append, Remove to remove, Delete to delete an emoji entirely.
This is already specified in the AP spec.

I think this could also be clarified in the FEP. For example, an alternative to this is Update(Collection) activity.

Create for new emojis, Add to append, Remove to remove, Delete to delete an emoji entirely.

What should a client put in their to and cc fields?

@sendpaws @deutrino @jody_racer @mkljczk I remember there was a post where you reviewed mitra, and pointed out to several missing things and bugs. What are your thoughts on it today? Does it have everything you need?

@phnt I don't see it that way. There are at least 4 different fediverse symbols. One of them was introduced by Ghost (IIRC) but it didn't gain much traction.

@deutrino @jody_racer @mkljczk mitra still doesn't offer as many moderation features as mastodon but maybe enough for a group of friends.