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

@harblinger

>delivery failed
>This contact doesn't support OMEMO encryption

@nimda pls help. I'm trying to establish a connection from were.social XMPP server
cc @arcanicanis

@waifu If I make a 88x31, would you add it?

@tallship Yes, it is a feature from GitHub Flavored Markdown

~~text~~ renders as <del>text</del>

@mario says Hubzilla will support this tag: https://hub.somaton.com/item/5d22eb3e-79eb-4e4e-9831-5aa269d70c4a

But people are also reporting that Fedilab doesn't display it correctly so I'm hesitant to enable this feature. The perceived meaning of the message can be very different without this piece of markup.

@harblinger @dino Dino enjoyer here. The only desktop client that just works and doesn't pull 1000 dependencies. I wouldn't call it fancy though

@realcaseyrollins Disappointing. Didn't expect that from a client.
Some servers might remove the <del> HTML tag, but even Mastodon doesn't do that since version 4.2

Testing strikethrough text

The result should look like the attached screenie

Hi @paul !

>relays

I don't know how relays work in Mastodon, but in Pleroma they simply boost posts. You can create a separate account on your Mitra server and follow relays from there. Relayed posts will appear in your federated timeline, but not in your personal home feed. This is what I'm currently doing at my own instance.

>bookmarks

Agreed, this feature would be nice to have.

@mikedev The path component was necessary when we were using did:ap, to distinguish between DID URLs and DIDs. However, with the introduction of 'ap' URLs this requirement can be relaxed. I'm just not sure if it should be.

@mikedev Okay, I think I'm starting to see the big picture here. When a group actor publishes Add or Announce activity which wraps another activity, the recipients should somehow verify the authenticity of a wrapped activity. With FEP-8b32 this is easy. Without FEP-8b32 you need to fetch the wrapped activity from its server of origin. However, when the group is private the activity would be private as well, and everything becomes complicated. The originating server may not know who is part of the group and who is not, and therefore it can't enforce privacy by requiring a signed fetch.

To work around this in his non-FEP-8b32 implementation of FEP-400e, @grishka invented "actor tokens": https://codeberg.org/fediverse/fep/src/branch/main/fep/db0e/fep-db0e.md

Am I getting this right?

Curiously, the authentication of wrapped activities is not described in FEP-1b12. I posted about this problem on SocialHub forum yesterday but haven't gotten a response yet: https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724/66

Is it so obvious that it doesn't need to be stated? Or is there a huge security hole in existing FEP-1b12 implementations because no one have bothered to think about this?

@mikedev I can spot several differences between this document and the latest revision of FEP-ef61:

- FEP-ef61 now uses gateways property, not gateway. I changed the property name because its value is an ordered list (and we already have replies and orderedItems, so a plural doesn't feel inappropriate).
- Canonical object ID has no path component. FEP-ef61 says that path is REQUIRED (according to RFC 3986, the path can be "empty", so I should probably change it to "path MUST NOT be empty").
- The value of proof.verificationMethod is a "compatible" ID, but according to FEP-ef61, "The value of verificationMethod property of the proof MUST match the authority component of the ap:// URL". In other words, it must be a DID.

Of course, all of that is up to discussion, and the spec can be changed if necessary.

>The sticky spots I see right now are abstracting a more portable url for profile-photo, cover-photo

We can use content-addressing. See Discussion / Media section.

>and ed25519 publickey

I assume you're referring to the need for it to be a server-owned key? Per FEP-521a we can add multiple keys to assertionMethod array. Each nomadic clone can use its own key for signing HTTP requests, only the identity key (the "authority" part of 'ap' URL) must be shared.

>You should be able to import the resulting record into any FEP-ef61 compliant server running on any fediverse platform and have one identity to rule them all.

In my implementation exported objects and the ones sent via S2S protocol will probably look the same, because in the future I will perform proof generation on the client side. This means the server will not be able to change published objects, its role will be merely of an indexer.

@pomstan wasm plugins can be written in any language, and probably can be re-used by other services. Also better security due to sandboxing

Lemmy devs are working on #WASM based plugin system: https://github.com/LemmyNet/lemmy/pull/4695

@grishka Looks interesting, I think writing a FEP is a good idea. The process is not dead yet

I want to implement private groups too but it is not clear which approach is better. We discussed private groups with @nutomic and he said that FEP-1b12 can also support private groups. There is an RFC, but AFAIK it has not been implemented yet.

And here's the documentation for @mikedev 's Conversation Containers: https://fediversity.site/help/develop/en/Containers

@julian

@julian

@grishka What are your thoughts on FEP-400e vs FEP-1b12 question? Is there a good reason to pick one over another?

@Codeberg Any chance you'll take a look at this issue: https://codeberg.org/Codeberg/Community/issues/1144 ?

This is a big problem for the FEP repository where people work on Fediverse standards. Looks like it can be fixed with little effort.

@raphael I also like gateways more, but almost all standard ActivityPub properties are singular words (even tag and attachment). Exceptions are items and replies

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/308

Further simplifying the spec by replacing aliases property with gateway (or should it be gateways?). The first gateway in the list is used to create MastoPub compatible URLs.

Gateways will probably be used to retrieve media as well:

#fep_ef61

@nimda @frogzone

The default size limit for local emojis has been changed from 50 kB to 256 kB (the current size limit in Mastodon)

It is not hardcoded anymore and can be changed with limits.media.emoji_local_size_limit config parameter (though I don't recommend doing that)

@frogzone @r @icedquinn @nimda @romin @p

I don't know. I'm seeing 3 greentext quotes here:

https://wizard.casa/post/018f222c-fb30-ccad-ea78-f7ba09eb0758

@liaizon You already have an account on public.mitra.social server :)

https://public.mitra.social/@wakest

I'll reset the password.