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

@tadano Everything looks normal. Have you looked at postgres log? Usually it can be found in /var/log/postgresql/

Maybe it's just postgres optimizing for performance by aggressively caching stuff in memory.

@tadano cached media is stored in a filesystem, it doesn't affect database performance

@tadano No idea what's going on here. Mitra process looks good (~60M?)

On my machine postgres never consumes more than 200M (it is usually at ~150M), though that might be due to that machine having only 512M memory in total. I also set shared_buffers to 32M in postgres config

I recommend executing mitractl instance-report, maybe it will show something interesting.

@lutindiscret @raphael @n0iroh @vincent Not really, I'd prefer to just put a hash into URL in a standardized way and use it to verify the integrity of a resource:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#media

Fediverse can be its own data storage network.

@vincent IPFS support in Mitra is rudimentary, it can save an ActivityPub representation of a post to IPFS but not much else.

During my experiments I found that IPFS node consumes too much resources and started to look for a more lightweight solution. Many ActivityPub servers already work as media caches, so in theory we can just use CIDs without the p2p network.

@vincent There was a problem with image property of dotmakeup actor. The url attribute of Image is set to null:

I changed my validator to be more lenient, but such representation doesn't feel right. I think it would be better to not add image at all if url is not known.

After fixing this issue I was able to resolve actor. Then I sent a Follow activity and dotmakeup sent Accept activity back to me. However, my server failed to verify the HTTP signature.
I'm not 100% sure but it looks like keyId parameter is incorrect, its value is https://kilogram.makeup/users/instagram (actor ID) when it should be https://kilogram.makeup/users/instagram#main-key (key ID).

@jupiter_rowland

>And unlike (streams), Mitra has switched existing actors to FEP-ef61 on recent versions.

Correction: Mitra still uses non-nomadic actors by default. I think implementation of FEP-ef61 (streams) is actually much closer to completion.

@mikedev @mike @miaq @jejord @AileenLalor @marci

@tesaguri @hongminhee

https://misskey-hub.net/ns#_misskey_quote type has not been standardized yet. I think this relation type and other things related to quotes (such as quotes collection) should be specified in a separate FEP.

>note that Misskey doesn't support it (both incoming and outgoing)

Yes, but Misskey and Pleroma support quoteUrl property (IIRC it is defined as as:quoteUrl). FEP-e232 + quoteUrl should work everywhere

@hongminhee No. It was mentioned in Threads announcement but I think they actually meant quoteUrl

@hongminhee You can use FEP-e232 in combination with quoteUrl property (there are other properties like quoteUri and _misskey_quote but they are supported by fewer projects).

@mischievoustomato You can create a DM by changing visibility setting of a post to "Direct"
But there is no "direct timeline" like in Pleroma and Mastodon

FEP-c7d3 had a major update: https://codeberg.org/fediverse/fep/pulls/387

Now it covers all aspects of ownership, including ownership transfer, and provides a comprehensive authentication and authorization framework for ActivityPub implementers.

#fep

@wjmaggos @Hyolobrika @ryan @tisha

It is already implemented in streams, by the way

@wjmaggos @Hyolobrika @ryan @tisha

>wouldn't some standards and norms about making account transfers work better fix this?

The solution I'm working on is similar to an account transfer, except your current account doesn't disappear. You can have multiple accounts on different servers but on the protocol level they are single account.
Even if widely implemented, that wouldn't significantly change moderation practices.

@vincent So, what do you think? This will make your service compatible with ActivityPub standard:

even if the URL doesn't resolve to an actual collection

@juanro49

@jupiter_rowland I can't see the reply from your nomadic account, but I figured out what's going on. Activities coming from your nomadic account are not portable and that causes authentication error on my end. I'll report this to the streams repo

@jupiter_rowland

@jupiter_rowland Is federation working between our servers? Activity delivery errors are gone, but I wonder if you're seeing my reply, like and connection request.

cc @jupiter_rowland

@giacelvecio @streams

@fentiger For those who want to implement a FediAM-compatible identity provider, what authentication protocol would you recommend?
Also, under what license this code is published?

@js Will fix, thanks for reporting

@js Nice tool. Are you going to open source it?