Notices by silverpill (silverpill@mitra.social)

@julian @activitypub Makes sense. Were NodeBB's own federated categories represented as users prior to this change? Do you assume that all groups are FEP-1b12 groups?
There was an interesting discussion on SocialHub on identifying FEP-1b12 groups and nutomic made a compelling argument that we should just assume that Group supports FEP-1b12 if there is no other indicator:

https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724/96

did:key specification was moved to a different location:

https://w3c-ccg.github.io/did-key-spec/

Its authors also removed sections dedicated to RSA and P-521 keys, but this is not a problem for Fediverse because we use Ed25519 keys.

A couple of weeks ago I moved to a new hosting provider (kyun), which is cheaper and better than my previous one, but seems to have much slower disks.
Response times have increased significantly, and that forced to me to review several query execution plans. In particular, featured collection is now generated much faster, and that may have an impact even if your hardware is good, because Mastodon instances tend to retrieve these collections when activities are delivered to them, making hundreds of requests at the same time.

https://mitra.social/objects/0195ca3c-14ee-6cce-2666-23c5a4e35fdc

@nimda If I remember correctly, you wanted to monitor mitra queues with Grafana. It is now possible. The /metrics endpoint that outputs queue sizes in OpenMetrics / Prometheus format can be enabled in config:

https://codeberg.org/silverpill/mitra/src/branch/main/config.example.yaml#L107-L109

@tadano You can enable the old behavior in v3.21.0 with federation.fep_c0e0_emoji_react_enabled config option.

FEP-c390 new implementations: Forte and Streams

https://codeberg.org/fediverse/fep/pulls/538

#fep_c390

RE: https://fediversity.site/item/904bbb48-03bb-415c-b2d4-52b1f8fefd77

@openwebauth Should https://codeberg.org/FenTiger/FedIAM also be mentioned among implementations?

@by_caballero @darius As a general recommendation - sure, this is what we should aim for. FEP-a4ed lists improving interoperability as one of the goals of FEP process.

@by_caballero @darius I think this shouldn't be a requirement, because implementation of some proposals, especially those related to moderation, might require breaking changes. Reply controls, for example.

@darius Both identity proofs and nomadic identity are useful even if the vast majority of servers don't support them, because they can be implemented without breaking federation, and because communities often form around implementations, and people within those communities can enjoy new features as they are rolled out.
Of course, utility increases with the number of supporting servers. We are working on that.

@darius @reiver I am not aware of other meanings of "feature x is already on the Fediverse". Could you elaborate?

@reiver @darius It looks like they moved the spec to https://w3c-ccg.github.io/did-key-spec/

I'll update the FEP. Thanks!

@darius @reiver What would you like to do with them?

DIDs have been in use on Fediverse for quite some time, first in identity proofs (this is like rel=me but with DIDs), and then as a foundation of ActivityPub-native nomadic identity.

@taoeffect

>Monetization features using cryptocurrency. And it must be cryptocurrency. Either #LightningNetwork or #Monero / #XMR

I experimented with this in my project Mitra: https://codeberg.org/silverpill/mitra
That server can process Monero payments for paid subscriptions.

It's also lightweight and easy to install, good for small instances.

>Real account migration (posts and all)

We are working on it as well. Mitra doesn't support full data migrations yet, but there are other projects that have complete implementation.

One of them is Forte:

https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584

@sun @liaizon

WASM MRFs were implemented in @kitsune (PR).
I am still not sure if this is necessary, the rule based system works well enough and can be easily extended when new threats emerge. Recently I added keyword filter to it and that fixed the Nicole problem.

>Luckily the spammer isn't as smart as nostr spammers

What do they do?

Is there any difference between this and FEP-f228: Backfilling conversations?

Same property, same use case.

@adiz Maybe it could be accomplished with nginx modules. I found one that allegedly can resize images on the fly.

>but I can't readily do that on my phone

Why? I never used those apps, but they are available even on F Droid

@adiz I think it is not possible. The only way is to implement transcoding in Mitra.

@fedify

>When you have thousands of followers, these operations add up quickly and block the HTTP response

Is that because Fedify implements some storage abstraction layer, so every storage write (3.) must be an independent operation, and writing thousands of items at once is not possible?

>What issues are you having with your current fan-out implementation?

Each delivery task looks like [activity, recipients].
These tasks are executed sequentially, and although HTTP requests to recipients are parallelized, all of them must complete before the next task can be started. Dead instances delay the completion of the task and slow down the whole queue.

I think this slowdown can be remedied by running multiple delivery tasks in parallel, but I am wondering if breaking them down into smaller [activity, single recipient] tasks would make the system simpler and more flexible.

@fedify Why there was a bottleneck at "create messages for each recipient" step?

My implementation works like your fan-out mechanism, but I am not completely satisfied with it, and I am thinking about switching to single-recipient queues.