onionmx
Movim
onionmx | Movim | |
---|---|---|
5 | 41 | |
191 | 1,689 | |
0.0% | 0.1% | |
0.0 | 9.4 | |
over 1 year ago | 11 days ago | |
Ruby | JavaScript | |
- | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
onionmx
-
Configuring email service in TOR
This readme is quite insightful.
- Onionmx: Mail Delivery over Tor
-
.onion email not found
For anyone curious, onion to onion (and even non-onion to onion) works today if the involved SMTP servers know how to handle it. For example, the OnionMX project. https://github.com/ehloonion/onionmx
-
Modern XMPP
Great question! onion vhosts ([email protected] addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate).
"Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.
Another example is if you wish to login as [email protected] by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections).
Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively
Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html
Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.
All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:[email protected]?join
Movim
-
The Matrix Trashfire
When https://siskin.im/ is seriously touted as the best iOS client for XMPP, you already lost 50% of the market share in the US. And if you don't have any usable app for 50% of your users in one of the most important markets, you can not really claim "interoperability", can you?
Don't get me wrong, it would be great if more people were using XMPP. Now that I am more involved in the Fediverse space I'm learning how many wheels are being reinvented and XMPP has already solved. If more people learned about https://movim.eu I'd be able to shut off Communick and move on to do something else to do with my life, but the reality is that XMPP failed to achieve critical mass because it never had someone to complete control the protocol.
- Movim 0.22.2 – A decentralized social platform built on XMPP
-
What's the status and progress of decentralized social media?
Let me put it in another way: of all the existing projects out there, which one does actually bring material benefit to the users and publishers compared with, e.g, Mastodon, Matrix, Movim or Nostr?
-
Thinkpad for Full Stack Web Development?
Any Thinkpad will do the job. I'm working daily on a T430 and X220 for both my personal and professional web dev work. I've been developing Movim for more that 10years on the same computer https://movim.eu/
- Movim 0.21: A federated, open-source web-based social Jabber/XMPP client
- Y a t il des incorruptibles du logiciel libre sur r/france ?
-
Ask HN: How might HN build a social network together?
For social networking atop XMPP, see https://movim.eu/
Combined with the in-development ActivityPub gateway from Libervia, interop with Mastodon, Pleroma and others becomes possible too. The decentralized social web space is quite active at the moment.
- How to rebuild social media on top of RSS
-
Instagram Is Over
If you don't care at all about poluar figures and just want to share content with people you actually know, https://movim.eu would be a much better alternative.
-
Ask HN: Private group chat with no registration
> No registration needed for group members
This one is the most troublesome I think.
Usually this is in a conferencing solutions though, so no such thing as chat rooms, I think.
Otherwise I would suppose something like XMPP with a web frontend, eg https://movim.eu/
ejabberd supports anonymous users, though I can't say if movim or any else web-client supports that natively
https://www.ejabberd.im/Anonymous-users-support/index.html