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

@expertplus Why Mastodon killed it? We are still using the same protocol and can communicate freely

@grindhold @dansup @helge @pfefferle @linos @laurin @MastodonEngineering @mkljczk Yes, unfortunately this is in the specs: https://www.w3.org/TR/activitystreams-core/#fig-an-object-that-is-both-a-place-and-a-gr-location
In practice multi-typing is totally useless and hinders interoperability, so all ActivityPub projects assign a single type to their objects.

@frogzone Speaking of Tor Browser, does it still set clearnet DDG as a default search engine? It would be better to use onion by default.

@torproject
@Hyolobrika @stefano @jeffcliff @justine

@mischievoustomato @tadano This is likely caused by a big number of expensive SQL queries running at the same time. Easy to fix, but let's collect more data first.

>so I re-pressed it, and now i realize it does post despite the unknown error thingy

I guess this is what Idempotency-Key header is for. I'll implement it

@mischievoustomato @tadano I have ideas about fixing CPU usage. But how did you get that message posted 4 times? Did you press "Publish" repeatedly?

@mischievoustomato Do you still have this problem? If it happens again, look at your HTTP server logs and note what resources are being requested and corresponding response times.

@dimkr Better view it here https://community.nodebb.org/topic/18364/fep-convergence-400e-7888-171b-conversation-containers-76ea

By the way, your input would be very welcome :)

@dimkr Groups are complicated, so it was necessary to explore different ways of implementing them. I think now we have enough data and can develop a mechanism that works for everyone, see this discussion: https://socialhub.activitypub.rocks/t/fep-convergence-400e-7888-171b-conversation-containers-76ea/4669

@dimkr If something requires special handling, send them a bug report. Otherwise it will be only getting worse

@ankokukishi @japananon Otter is built on QtWebEngine, which probably uses a fairly recent Chromium/Blink

@japananon @ankokukishi Yes. It should be installed on a different subdomain

@ankokukishi @japananon The default frontend requires a relatively modern browser, so I'm not surprised that Pale Moon didn't work.
Is Seamonkey based on an up-to-date Gecko engine? Firefox ESR level would suffice. Are there any errors in browser console?

Also, Mitra is compatible with Bloat frontend which should work everywhere.

did:dns might be a good choice for FEP-ae97 clients.
It supports key rotation, but a web service is not required, so people don't need to deploy anything to create an identity. Just generate a secret key in your client, add a resource record to your domain and start posting.

#fep_ef61 #fep_ae97

@by_caballero

>why is support for more did methods an assumed goal?

Because extensibility is good. New DID methods are constantly being invented and there shouldn't be any artificial restrictions on their use.

>for whom and in which use cases is a non http protocol handler justified?

In an 'http' URL, the authority is derived from the domain name. In our case, authority is derived from a cryptographic identity, so a custom URI scheme is more appropriate.

>why is did:key important?

did:key doesn't depend on any external services and is the easiest to implement.

>why is ap: the best possible url scheme for the AP protocol?

It works and so far no other scheme has been proposed.

@erlend @bnewbold @arcanicanis

@eltenso A public reply

cc @elvecio

@steffo

>“even if no fedi client does it atm”

There is only one: https://codeberg.org/silverpill/fep-ae97-client

@japananon Lightning is insanely complicated. I've been following its development from the very beginning, and the base idea is fairly simple. But they kept adding more quirks and layers to it and at some point I just lost the track. I don't see a future where it becomes usable without being completely centralized.

@bnewbold Of course, a new syntax for DID authorities would be preferable

But standardization of it may take many years. And after that people will need to update all existing URI/URL parsing libraries and software that depends on them.

@arcanicanis @by_caballero @erlend

@bnewbold There is no advantage in using DID URLs. That severely limits the number of DID methods developers can use, and excludes the most important method, did:key.

You're right, new URI scheme is much better. This approach is being explored in FEP-ef61 (where ap:// scheme was proposed).

ActivityPub IDs are RFC-3986 URIs, and that RFC doesn't forbid non-DNS naming authorities (idk about WHATWG standard). However, you can't build a valid RFC-3986 URI with plain DID because the portion after the last colon is parsed as a port number. Two solutions has been proposed:

- Percent encode DID: ap://did%3Akey%3Az6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor
- Pretend that we are using IP address from the future: ap://[vd.did:key:z6MkvUie7gDQugJmyDQQPhMCCBfKJo7aGvzQYF2BqvFvdwx6]/actor

@arcanicanis @by_caballero @erlend

@mischievoustomato This is not a problem, as pg constraint violations are handled by Mitra. But these messages fill postgresql log, so I'll be rewriting the code to avoid them.