Hello, thanks for the report!

Himalaya is currently at v0.9.0 and so you should really use the latest 
version and see if the bug appears there. What does your configuration 
file look like?

What's the status here?

Is joining Matrix a no-go for you, toastal?

I know Element has updated their IRC bridge now, so the issues might be 
fixed, but I'm a bit afraid to risk getting into the same situation of 
kicking a lot of users unfairly out of the channel.

`pimalaya-email` currently operates on the duality between the `Backend`
and `Sender` traits. These are sensible analogues to IMAP and SMTP,
respectively, but they do not have the granularity that might be
necessary to express the full range of email backends and their
functionality. Additionally, their naming can be a bit confusing. 

I propose a pretty radical refactor into these traits instead:

---

    /// Connect and disconnect operations on a backend.
    pub trait Connect {
        fn connect(&mut self) -> Result<()>;
        fn disconnect(&mut self) -> Result<()>;

Some additional documentation about the duality between the two traits
is also added to the lib root.
---
 email/src/lib.rs | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/email/src/lib.rs b/email/src/lib.rs
index 582b8ee..7e88d61 100644
--- a/email/src/lib.rs
+++ b/email/src/lib.rs
@@ -15,6 +15,21 @@
 //!  - [`Flag`](email::Flag)
 //!  - [`Backend`](backend::Backend)
 //!  - [`Sender`](sender::Sender)
[message trimmed]

Hi,

I'm trying to host some static files with pages.sr.ht, but from my
testing, it seems like the `Access-Control-Allow-Origin` header is not
set. Setting it to `*` would be very useful for static hosting uses,
e.g. in my case for accessing my RSS feed from another domain.

Are there any reasons this has not been set already? I don't immediately
see any clear security issues with it [1], and it would be a very
welcome addition!

[1]: https://annevankesteren.nl/2012/12/cors-101

--

> Is this where the cool kids hang out nowadays?

Grab your rollerblades and join me in the DeLorean. We're heading back to 
the 90s 😎

> This sounds a lot like WebFinger[0]. Look at the "Identity Provider
> Discovery for OpenID Connect" section on its RFC

I hadn't heard about WebFinger before, but it seems perfect for the job.
Why reinvent the wheel when there's already a standard for it, right? I
found an existing implementation [0], but it is outdated and hasn't
changed in a while. As such, I did the only sensible thing (not) and
started our own WebFinger implementation [here][1]. The protocol is
relatively small, so it shouldn't be that much of an undertaking.

I actually think WebFinger might be a good fit for contact discovery in
Himalaya (or cardamom, when that is ressurected), so this might bear
fruit in other areas as well.

Glad to hear you like the idea Clement!

I now have a *very rudimentary* server/client implementation in the 
[source code][1] which just uses local TCP sockets to communicate, which 
should be easy to port into remote communication.

There is a case to be made that we may not need to follow the HTTP 
protocol at all if all communication is supposed to be done via the toe 
tooling. We could just have our own simple commands. However, if we want 
interoperability with something like curl, then we have no choice. Also, 
adding a security layer would probably be easier if we can utilize 
already existing HTTPS implementations, so I guess we should just give 
in.

Hi Pimalaya folks,

My friend [Victor][0] (he's in the Matrix room) gave me this idea a
while ago, and I have been thinking quite a bit about it since. It's a
modern take on the [Name/Finger protocol][1] that would allow users to
easily share information they want to make public with other users on
the network. Think stuff like your name, email, PGP keys, etc. Nothing
you wouldn't share on your homepage. Additionally, we could add a
feature where users could share their current status, which would then
be displayed on a central feed containing all the newest status
messages, kinda like <status.cafe>.

Before diving into development, I wanted to get your input and feedback.
What features could be included? What types of technologies and