silverpill

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.

Thanks @graf

@mkljczk @jody_racer

@phnt Since then is associated with corpoization?

@jody_racer Yes, this is how it is supposed to work.

@mkljczk I see a lot of CSP errors, but they don't look critical. There is a request to /api/v1/pleroma/admin/config that results in 404. And a request to /api/v1/accounts/verify_credentials that results in 401. The latter may explain why login doesn't work.

@jody_racer

@deutrino @jody_racer @mkljczk Pleroma development is slower than it used to be in Gleason era, but they are still doing feature releases. Akkoma seems much less active

@jody_racer What account? And what do you mean by can't federate?

@greyarea Alright, I implemented the auth mode. It's not difficult, but it requires the actor of outer activity to be the same as the actor of inner (plaintext) activity. With base mode (5.1.1), the actor of outer activity could be different, which means we can hide the real sender.

Do you think it's worth doing this?

I think authentication of the sender at the HPKE level shouldn't be necessary because the inner activity is self-authenticating (includes integrity proof).

@jody_racer Hm, doesn't work for me either

@mkljczk Is Mitra backend still supported?

@jody_racer @mkljczk Use Mitra. If you want Soapbox-like frontend, you can use Nicolium which is compatible with Mitra.

@xailog @liaizon The idea is very simple:

- Find a grassroots ecosystem, which is not very well known to general public
- Start promoting it to general public, while inserting your name or brand in every communication.
- People not familiar with the ecosystem think that you are very important.
- You get accolades, invited to conferences, receive grants and contracts.
- Grassroots ecosystem slowly dies and is replaced by structures that you control.
- PROFIT

@liaizon The documentation is incomprehensible. Meaningless machine-generated walls of text.

@liaizon Yes, what about it?

I see a bunch of startups that are trying to sell fediverse to eu governments.

@liaizon As far as I can tell, "open social web" is what commercial platforms like WordPress and Ghost use instead of "fediverse".

@potatomeow I don't know but it's a bad signal

@greyarea Yes, proof covers all properties of the activity. But I can't omit encap_key, it is required by SetupBaseR function defined in section 5.1.1

I've read a bit more about DHKEM and now I am even more confused. Isn't encap_key an ephemeral key? The library I am using describes it as such:

https://docs.rs/hpke/latest/hpke/trait.Kem.html#tymethod.encap_with_rng

Derives a shared secret and an ephemeral pubkey that the owner of the reciepint’s pubkey can use to derive the same shared secret.

This "ephemeral pubkey" is what I labeled as encap_key. It is later included in fep0806:cipherData

-----

I think it's okay to have no forward secrecy, the goal of this FEP is to describe a simple encryption mechanism that anyone can implement. I'll just warn readers about its weakness.

A standardized emoji catalog allows a C2S client to ...

But the proposal doesn't fully explain how to do that. In particular:

- How catalogs are created? (I wrote a FEP that provides some recommendations, FEP-9f9f: Collections)
- What activities are used to update a catalog?