From Knut Magnus Aasrud to ~soywod/pimalaya
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?
From Knut Magnus Aasrud to ~sircmpwn/sr.ht-dev
What's the status here?
From Knut Magnus Aasrud to ~soywod/pimalaya
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.
From Knut Magnus Aasrud to ~soywod/pimalaya
`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<()>;
From Knut Magnus Aasrud to ~soywod/pimalaya
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]
From Knut Magnus Aasrud to ~sircmpwn/sr.ht-discuss
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 --
From Knut Magnus Aasrud to ~kmaasrud/inbox
> 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 😎
From Knut Magnus Aasrud to ~soywod/pimalaya
> 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.
From Knut Magnus Aasrud to ~soywod/pimalaya
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.
From Knut Magnus Aasrud to ~soywod/pimalaya
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