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

@delta

>Any sufficiently advanced P2P messenger will eventually re-invent a custom, partial form of e-mail

That's correct, pure P2P is a pipe dream. The solution, however, is federation, and email is only one protocol among many.

ActivityPub should work just as well, but it is modern, extensible, with a rapidly growing userbase, and may eventually replace email. Consider supporting it. The secure fediverse messenger still doesn't exist, and many have promised to build one, but you can be the first who actually delivers.

@harblinger The latest update should fix the occasional encoding error.

https://wizard.casa/objects/018f735e-4943-2fbe-3d20-a3818049005f

@nimda

@gabriel

>Telegram has launched a pretty intense campaign to malign Signal as insecure

Good. They are fighting, but we are growing.

@julian @federated Apparently only the top post is federated but not replies.

https://socialhub.activitypub.rocks/t/id-normalization/4233/3

Someone wrote a simple installation guide for #Mitra

https://buck.al/mitra-installation/

@Hyolobrika @tallship It already can work as onion service, so domain name is not strictly required. And once I implement nomadic identity it will be able to work without internet connection.

@tallship This is how I imagine the end game for Mitra. Just a single executable, without renting anything from anyone.

@liaizon @grunfink @mikedev @streams @nodebb @julian Mitra transforms Event objects into posts, that works reasonably well. I'm not against extended support but I'd like to wait until some standard in this area emerges. As far as I know, existing event servers use slightly different protocols.

@blog was working on better interop

https://event-federation.eu/

@pomstan

Yes.

https://github.com/discourse/discourse-activity-pub

It is currently being tested at SocialHub (though only selected topics are federated, @feps@socialhub.activitypub.rocks and a couple of others)

@monero @OrangeFren

@OrangeFren @monero Activity in Lemmy network might have subsided since the Reddit Migration, but it is certainly not dying. Today there are 768 instances with the largest one having 18469 MAUs.
The important thing about federation is that there is no downside. You get a regular forum with all benefits of a self-hosting, but now people don't have to register on it in order to participate. For example, monero.town currently has 83 MAUs, and you can access that audience for free simply by using a different software.
I previously mentioned Discourse, which has a federation plugin, but it is not the only forum engine to choose from. NodeBB is working on federation (almost finished), and Flarum too. These engines will be fully interoperable with Lemmy, and partially with micro-blogging apps like Mastodon and Threads.
So, yeah, you're right about this being an uncharted territory, but I see a lot of potential here

@OrangeFren @monero Why make a non-federated forum? You can run a Lemmy or a Discourse instance, and let people from monero.town and beyond participate in discussions. Otherwise there won't be much activity

@Hyolobrika @kycnotme I haven't heard of that. Probably it was some other "DEX"

@kycnotme Some of their claims appear highly dubious.

Especially this: https://particl.wiki/learn/marketplace/smsg/

>SMSG is a decentralized P2P message mixnet where all nodes store a copy of everyone’s end-to-end encrypted messages and data

Sounds like a bunch of buzzwords thrown together. Do they even know what mixnet is? Apparently their protocol is based on the abandoned Bitmessage protocol: https://kewde.gitbooks.io/protocol/content/data-storage-network/smsg.html

But there's no detailed description of how it works. Looks like they just made it up.

>It operates parallel to Particl’s network and is hosted on the same nodes running the blockchain.

Even if this SMSG protocol really exists, it is not clear who runs the nodes. Their explorer says there are 74 peers, but this number can be fake. Or these nodes can be controlled by developers.

The app has Tor support, but it is not enabled by default:

https://particl.wiki/tutorial/privacy/tor/

Users might not be aware of that, so whoever operates the nodes can de-anonymize them.

-----

I'm not saying it shouldn't be listed. But until their software gets an independent audit, everyone should treat it like a regular centralized exchange which for some reason wants you to download an executable.

@nimda @clemv I'll make importer ignore this error in the next release, but it would be nice to know what fediverse address causes this.

@clemv It shouldn't stop if one profile is not available, but maybe there is some other error. This feature is experimental, after all :)
The server imports follows from your CSV one by one. Could you tell me the address of the first follow that wasn't imported?

>I'm redirected straight to my profile with no further info on its state.

That is expected.

@nimda grep ERROR on mitra log may provide some info

@tedu @article_interop

Found the answer here: https://funfedi.dev/support_tables/generated/object_types/

Sharkey seems to be ignoring the name, I guess this means Misskey does that as well.

@tedu @article_interop There might be popular services where name is ignored completely but <h1> in content gracefully degrades. If that's the case, <h1> (or <h1> plus name) would be preferable.

AFAIK Mastodon doesn't have this problem and will display Article.name. I don't know about the others.

@clemv The CSV should have one fediverse address per line (Mastodon export format), 500 items max. The process may take 5-10 minutes.

But there is a difference between "import follows" and "move followers" features. You should be able to import follows from anywhere. Followers can only be moved between Mitra instances (because no other software supports this feature).

@nimda

Article Interop WG: How to represent titles?

Should title be inserted into Article.content as an <h1> tag, or should it go to Article.name?

@article_interop

@mikedev All I know is that they are trying to make JCS based proofs compatible with JSON-LD processors.

At least this change doesn't invalidate existing proofs (those without injected @context). It could have been worse