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

@sendpaws @mischievoustomato

I think this is because husky and mitra-web use different payload formats, multipart data and JSON. Effective payload size might be different depending on the format.

Default upload limit is 20 MB. Max payload size is twice the upload limit, 40 MB by default.
If the size of your image is not anywhere near those limits, there must be a bug somewhere.

@sendpaws @mischievoustomato

journalctl -u mitra
if you are using systemd

@sendpaws @mischievoustomato

I tried to upload an image with husky and it worked. Is there anything unusual about your image?

I think the best way forward would be reporting this problem to Husky dev: https://github.com/captainepoch/husky

@sendpaws @mischievoustomato

Fedilab doesn't work, I don't know why https://codeberg.org/tom79/Fedilab/issues/814

I'll check Husky

@sendpaws Husky should work better than others. What's the issue with pic upload, does it affect Pleroma too?

@sendpaws This particular problem was fixed in mitra version 3.16.0

But there are other issues with this client (I assume it's Mastodon official?), which I don't how to fix

@rafael_xmr @monero This app connects to 30 clearnet domains and all images are stored on nostr.build.

@lionroe Sounds complicated, and the biggest flaw of OpenBazaar still remains: the lack of web client. We discuss this article because it is available on the web. Lemmy and other Fediverse apps are successful because they have web clients.

Why not start with existing federated software like flohmarkt? Make it federate over Tor (maybe it already does). That would solve the hardest problem, discovery. Other features can be added later.

Vendors will host everything themselves, so there is no need for any incentive model.

@monero

@evan @scott @julian @mikedev @mario In our case contextHistory resolves to a collection of activities, so thread would not be a good name. Personally, I am not against using thread for collections of posts, but other developers seem to prefer context.

@scott @julian @mikedev @mario Yes, we are discussing a new property, contextHistory, which is supposed to replace context on posts. That would make conversation container implementations compatible with projects that use context in other ways.

@chris108 @sendpaws @koimoa What I am planning to do:

- Change the phrase to "Wildcard rules are applied last".
- Reverse the order of rules in list-filter-rules output:

Would that make it easier to understand?

@helge

>is good or bad compared to having the one clickable URI

URIs are harder to read and we don't how long joinmastodon.org will last

@tesaguri @fedify

It appears that regular Likes are not included, only Likes with content (and EmojiReacts).
Adding this information to the FEP: https://codeberg.org/fediverse/fep/pulls/488

@chris108 @sendpaws @koimoa Yes, I think you are right.

Internally, they are checked in order: from less specific to more specific. This means wildcards go first, and I had that in mind when I was writing the doc. But from the end user's perspective, the order is reversed.

@koimoa @sendpaws Not using Zot, but I figured out how to achieve nomadic identity with ActivityPub alone. This nomadic ActivityPub flavor is described in FEP-ef61.
Mitra supports it, but the implementation is incomplete and not practical for everyday use. I plan to finish it someday, but it will require a lot of work. However, Mike Macgirvin (who created Zot) implemented FEP-ef61 in his project Streams, and his implementation is more complete than mine.

@sendpaws @koimoa Mitra has federation filter, which works like Pleroma MRF:

https://codeberg.org/silverpill/mitra/src/branch/main/docs/filter.md

It is much less flexible (can't run arbitrary code), but filter rules are stored in database, and can be edited with CLI (and hopefully via Admin Web UI in the future).

>keyword filtering

I don't think we have that. But if you need this (or some other) moderation capability, let me know.

Thanks @fedify @tesaguri, I'll mention this in the FEP

@tadano @sendpaws @Forestofenchantment Will do

@fedify

>emojiReactions

Is it a new property, and there is some prior art?
I should probably mention it in my Emoji reactions FEP

@a

>activitypub can't solve this on its own, but implementers of social services can for example abstract away "storage" into a separate component that runs something like solid

Part of ActivityPub standard is Client-to-server API. It is poorly specified, but by using this API one can move most of the application-specific logic to clients, and then use servers for storage (and authentication, permissions etc).

We can go even further and make data portable. This makes ActivityPub like ATProto, but much simpler and actually decentralized. You can read about implementation in this document:

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

@arcanicanis