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

@frogzone Several edge cases still exist that are not handled properly

For example #hashtag's doesn't work

The Social Web Foundation is such a disgrace. One of the most flagrant attempts to co-opt a grassroots movement I've ever seen.

But on the other hand, naming it like that is an interesting move. I'm enjoying watching how all those Bluesky and Nostr shills, who were trying to re-define "Fediverse" for years, are finally getting a taste of their own medicine.

@frogzone Your server is already up to date

@Hyolobrika Mitra is partially compatible with Lemmy: comments, upvotes/downvotes, syncing of threads.

NodeBB is a forum engine that implemented AP, currently in beta: https://community.nodebb.org/post/101095. But I don't know about Lemmy interop

@frogzone

>Bug 1

Paragraphs in bio are supported now

@frogzone mitra 3.5.0 displays PeerTube thumbnails, and target=_blank is added to links

@mochi @tengkuizdihar E2EE would be really great. A number of projects are interested in supporting it, but developers don't have the bandwidth for R&D

Here's a brief history of E2EE in Fediverse:

https://codeberg.org/fediverse/fediverse-ideas/issues/3

@helge @docbibi HTTP headers is such a good example. Imagine if we had to use JSON-LD to prevent conflicts in HTTP header names

@tadano When you're following someone, their messages are delivered to you ASAP and following their instance relay won't help (and may actually increase delivery times). Messages from people you're not following might be delivered to you with delay, or not delivered at all, that depends on many factors. Following their instance relay will ensure that messages are delivered.

@tadano No, it doesn't have a relay actor.

>hopefully enabling quicker federation

Could you elaborate?

@julian @SorteKanin

published property can exist on activities too. Some implementation already does this but I don't remember which one

@raucao @feld These things are on the roadmap, but solutions are supposed to be developed in-house.

@manlycoffee They are only "thriving" in a way gambling industry is thriving.
However, if you consider its original goal, web3 failed miserably. Nothing in web3 / defi / dao world is decentralized, and nobody even cares anymore

@julian @trwnh @mikedev

There is a draft of Conversation Containers FEP: https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md
And I've come up with a plan for FEP-400e and FEP-1b12 convergence: https://socialhub.activitypub.rocks/ap/object/e9b7fb34c4af9291b9b98095e661789d

@raucao @feld It's not about control, it is about resources. Some developers may want to implement these FEPs, but that requires a lot of effort (especially if you're are among the early adopters), and they can't commit to it. Other so called "protocols" are paying developers, so stuff gets done much quicker.

@sun Mitra requires username to be unique across portable and non portable accounts. Other implementations may handle this case differently, but generally 'acct' URIs should have 1-to-1 relationship with actors

@sun Mentioning and handles work as usual, for example I can mention @nomad

Portable actors can be replicated to multiple servers (gateways), so in theory you can have multiple webfinger addresses:

1. https://mitra.social/.well-known/webfinger?resource=acct:nomad@mitra.social
2. https://public.mitra.social/.well-known/webfinger?resource=acct:nomad@public.mitra.social

But in practice you will likely use only one address because only one clone can be compatible with non-FEP-ef61 servers (they require location and actor ID to have same web origin)

@mikedev

I would prefer to use a single type, but ['OrderedCollection', 'Context'] is also an option. The type will be defined in w3id.org/fep namespace with full URI being https://w3id.org/fep/171b/Context (assuming this idea survives the community review)

@trwnh @jesseplusplus @julian I'm also working on a FEP, it is based on Conversation Containers and FEP-7888: https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md

Still not sure about outbox and collection-actor thing. I'll try to implement Conversation Containers and obtain an informed opinion

@mikedev draft: https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md

It is based on the original text, but I added several clarifications, and also some new requirements:

- Compatibility with FEP-7888
- The recommended type of collection is Context
- Using FEP-c7d3 framework for authentication

But it still should be compatible with your implementation. If it will diverge in the future, I'll pick a different name