Notices by silverpill (silverpill@mitra.social), page 4

@justin @jdt Shouldn't the entire Note/EncryptedNote be signed with the client's key?

@benpate @hrefna

>filled with actual implementers

Oh yes, I would love to see that. Participants should also be required to communicate using the software they are developing.

@feld Can't we use it in Fediverse? I don't know how iroh works, but if it can deliver arbitrary JSON object to another machine, then it is compatible with ActivityPub

@justin @jdt Already following :)

Some thoughts:

- content is supposed to be human readable. I think it would be better to use a new property, for example encryptedContent (and possibly a new type), to make it clear that this object shouldn't be presented as a "post" by other software.
- instrument should be used only in activities
- AP currently allows null IDs, but it is probably an error in the spec, see discussion: https://github.com/w3c/activitypub/issues/476
- It would be nice to encrypt metadata too, at least partially (tags, attachments).

@thomas @yunohub In other news, I added some info about update process and versioning to the readme: https://codeberg.org/silverpill/mitra#upgrading

@thomas @yunohub It looks like starting with Debian 13 rustup will not be needed to build mitra.

My medium-term target is 1.75, but they already have rustc 1.82 in testing.

@suno Tuba is currently not among supported clients, but I like it

@suno

>the media files attached to the message simply disappeared.

It doesn't happen when I edit the message in mitra-web
If you are using a different client, I suggest sending a bug report to them.
Also, the list of supported clients can be found in README.md : https://codeberg.org/silverpill/mitra#supported-clients

>I hope the cleanup will remove unrelated files from the filestore - because searching for it manually is almost a hopeless task. There are thousands of image files that are similar to each other.

Yes, they are removed automatically.

@suno Hello, I'm glad you liked it!

I noticed some federation issues between my server and yours (though by now they seem to be gone). Did you have another fedi software installed there before mitra?

@aRubes This is fine - the title is readable and whitespace is preserved. Thanks for the info!

Mitra now allows level-1 markdown headings, so I started adding them to @weekinfediverse posts:

https://mitra.social/objects/01930cdc-f769-dbdb-3236-475008bd386d

Some platforms will strip the <h1> tag, but they should still display title as a plain text.

@frogzone @r @thendrix 'private' is followers-only, right? you can't respond to someone else's message, or your own?

@mochi Gateways are supposed to keep inboxes and outboxes in sync. Clients retrieve activities from inboxes and outboxes, so if gateways are synced, clients will be synced as well.

But I don't know yet what is the best way to sync collections. Maybe we need to use FEP-8fcf or a similar mechanism.

@mochi I want Mitra to work in user-owns-data mode too, and my current plan is to re-purpose it as FEP-ae97 client without a total rewrite. It already does almost everything a rich client is supposed to do, I just need to replace 'http' URLs with 'ap' URLs, sign all objects and replace inbox deliveries with outbox deliveries.

The main difference between a regular ActivityPub server and FEP-ae97 client is that server must be online all the time, whereas FEP-ae97 client is local-first and communicates using gateways

...so it might not be necessary to ditch your current codebase

@mochi What are your thoughts on FEP-ae97 ? Is it suitable for user-owns-data applications?

@erincandescent @trwnh @evan @jenniferplusplus @mikedev @scott @julian @trwnh
The name of the property could be different, but I think it is useful to have two collections:

- "Thread" is easier to implement, and in any case, software needs to keep track of reply trees, one way or another.
- "Context" is a bonus. It contains everything related to a conversation, including reactions and edits. Some applications may not need it, and for some it might be difficult to implement, so it should be optional.

My estimation is that implementation of "Context" + "Thread" will require roughly the same amount of effort as implementation of "Context" alone, so for those who want "Context" this separation should not be a problem. If software doesn't keep track of activities it can provide empty "Context", but their Add activities should nevertheless have it in target. Perhaps in the following form:

@hongminhee

conversation containers by @mikedev solve that problem. With this mechanism in place not only replies are synchronized, but also reactions and edits - everything that happens in a conversation.
It also enables reply controls, private groups and (better) followers-only posts.

Hello @theorytoe @theorytoe

In what areas mitra frontend could be improved?

@mischievoustomato

@helge A standardized property already exists, digestMultibase: https://w3c.github.io/vc-data-integrity/#resource-integrity

@possibledog @summertime Everything that is possible in ATProto is also possible in ActivityPub. In fact, ActivityPub is a much more capable protocol. Developers even could use DIDs (real ones, not did:plc) for data portability: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md