progval
Support encrypted rooms
This will have to wait for libolm (or an alternative) to be documented; ideally with an Elixir/Erlang binding.
This might be useful to allow access to attachements: https://github.com/seirl/matrix-decryptapp
Quoting weechat-matrix's README:
In the browser by using matrix-decryptapp. This is a static website which cannot see your data, all the decryption happens on the client side. You can either host it yourself or directly use the instance hosted on
seirl.github.io. This weechat trigger will convert all youremxc://URLs into clickable https links:/trigger addreplace emxc_decrypt modifier weechat_print "" ";($|[^\w/#:\[])(emxc://([^ ]+));${re:1}https://seirl.github.io/matrix-decryptapp/#${re:2};"
May be very useful to avoid dealing with OLM directly: https://github.com/matrix-org/pantalaimon
I started working on a branch to support Pantalaimon: https://github.com/progval/matrix2051/tree/pantalaimon
Unfortunately the version of Pantalaimon in Debian is unusable (because of https://github.com/matrix-org/pantalaimon/issues/109 ) so I am not interested in testing this further myself for the moment. Feedback is welcome, though.
Oh thank you this was exactly what I'm looking for.
I even did already setup Pantalaimon, I just need to check that I change the port that matrix2051 with Pantalaimon.
I will get back in a few days.
Br,
Björn
I started working on a branch to support Pantalaimon: https://github.com/progval/matrix2051/tree/pantalaimon
Unfortunately the version of Pantalaimon in Debian is unusable (because of matrix-org/pantalaimon#109 ) so I am not interested in testing this further myself for the moment. Feedback is welcome, though.
Can you rebase the branch?
What works:
- Channel name
- User name in channels
Warnings about:
channel, channel, channel commas are not allowed in channel names (ISUPPORT MAXTARGETS/TARGMAX not implemented?)
the warning is unrelated, it happens when IRC clients send too many joins at once
I noticed there still an unencrypted connection that is from time to time (at least it appears in the client list).
oh you mean it's not going through Pantalaimon? Right, I'll try to look into it
Val Lorentz @.***> writes:
oh you mean it's not going through Pantalaimon? Right, I'll try to look into it
It is but first there's an unencrypted that is opened I think.
Val Lorentz @.***> writes: oh you mean it's not going through Pantalaimon? Right, I'll try to look into it It is but first there's an unencrypted that is opened I think.
Is this the issue that needs to be fixed before you can merge the proxy feature?
Yes, and I'm also still unhappy with the realname hack. A CLI option might be better
Val Lorentz @.***> writes:
Yes, and I'm also still unhappy with the realname hack. A CLI option might be better
The realname "hack" actually works quite good in my opinion as you can define it per connection, it fits to the design that the service itself is stateless until an option is passed to via the login parameters.
Maybe there's a better parameter to put the proxy option into.
Any news on this issue? Maybe better to have a solution even if it isn't perfect.
Actually I haven't got Pantalaimon setup yet (I ran into some unrelated issues). I'd appreciate if you could pinpoint specific issues you have with Pantalaimon along with a tcpdump
Someone tells me Pantalaimon + Matrix2051 (pantalaimon branch, ea1f13473a6089c8b73837ea99e1a32932116a50) works for them. So it's probably just a matter of deciding the best way (GECOS vs PASS vs CLI argument vs ???) to tell M51 how to connect to a proxy.