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

@mischievoustomato Looks similar to this problem: https://codeberg.org/silverpill/mitra/issues/74

@Hyolobrika If those people are re-inventing wheels (most of them are), this is just a waste of time. In order to make a difference your network should become as widely used as email while remaining decentralized. And Fediverse can be that network.

@Hyolobrika FEP-ef61 is similar to Nostr and I think it can be implemented in all existing ActivityPub applications. Including Ibis

@Hyolobrika Yes, I've heard of it, but I'm not following the development of this platform.

He should also use ActivityPub. Small experimental networks were necessary in 2000s and maybe even in 2010s, but today, after two decades of experimentation with decentralized applications, we need to focus on actually solving the problem

@Hyolobrika https://github.com/Nutomic/ibis/

@japananon Since version 3.7.0 Mitra stores original URL of a downloaded media attachment, so it is possible to analyze what eats up the space (that would require executing SQL queries though)

@jupiter_rowland @strypey @mikedev @LaurensHof

And FEP-c390 is a predecessor of FEP-ef61. It describes a method of linking ActivityPub actors to cryptographic identities (using signed attachments). That enabled permission-less migration of followers, but not posts. Later, a method of linking *any* ActivitiyPub object to cryptographic identity was discovered, and that eventually became FEP-ef61

I don't think FEP-c390 should be used for migrations or nomadic identity, but it might still be useful as a cryptographic equivalent of rel=me linking.

@hongminhee I thought Pleroma uses

Did they change the endpoint? Or perhaps it is different in Akkoma?

@julian This pattern can also be used in Accept and Undo activities:

@julian

No, that's for target property. Here's an example of Add.target from Streams:

In my code I have a handler for Add activity, which then sends activity to one of the other handlers:

- Add{target: featured}
- Add{target: subscribers}
- Add{target: context}

Currently I use heuristics to determine which one to use. But with Add.target.type == <meaningful type name> the code would be simpler and less fragile.

Do you have something like that in NodeBB? I wonder how others solve this "routing" problem

@julian @evan @jenniferplusplus @mikedev @erincandescent @evan @trwnh

>7888/171b use context whereas 76ea uses a new property thr:thread

I think context is good enough. Streams and NodeBB already provide this collection and Mitra will too.

>171b specifies a new object type Context

It is for easier identification of conversation-Add activities. My server may receive many different kinds of Add activities, and it would be nice to have some indication of what collection is being modified.

This is just an idea though. Streams uses Collection type

>Collection items:

My use case requires items to be activities, but I can support both variants of context collection. Conversation activities can be also put into a different collection.

@steve

Yes, you can use pytest to check FEPs in the repo: https://codeberg.org/fediverse/fep/src/branch/main/scripts#setup-for-running-pytest

There's also an online tool by @andre: https://fedi.builders/fep/

@expertplus Click on three dots on your profile page and select "Link minisign key".

The process is a bit complicated, though. You can read about Minisign here: https://jedisct1.github.io/minisign/

@mariusor @dmitri Yes, a built-in relay. Direct communication between servers, 100% ActivityPub

@dmitri @mariusor Server operators who want to provide data can host a relay (for example, Pleroma has a built-in one). People who want to access that data (for whatever purpose) can subscribe to those relays.

@mariusor

None of those things need an external provider.

There is also an EEE aspect of it, because they use custom API instead of ActivityPub.

For every complex problem in the field of decentralized network engineering, there is an answer that is clear, simple, and wrong:

Auxiliary Service Providers

@bengo

streams, a combined server-client by @mikedev

The "decoupled client" is a subject of another proposal, FEP-ae97 (it's based on FEP-ef61). I made a simple command line client (https://codeberg.org/silverpill/fep-ae97-client), and implemented server-side C2S API in Mitra.

@ilja

@bengo

>Identity/Authenticity/Data Decoupling

In this section you're basically describing FEP-ef61. Do you know that implementations already exist?

@ilja

@bengo did: is not suitable because not all DID methods support DID URL syntax (for example did:key). In earlier versions of FEP-ef61, a wrapper DID method was used (e.g. did:ap:key:...) that could augment any DID method with DID URL capabilities, but implementation experience showed that ap URLs are easier to work with. They also better fit into origin-based security model used in vanilla ActivityPub.

@ilja