There is a bug on my end. In the URL being posted, you can see that it's adding a colon at the end of the URL (as though a port number might follow but there isn't one).

I've fixed it in a local branch this weekend, but I've also see set up a matrix server on my side. I'm going to go through the whole plugin and revitalize it.

There is a bug on my end. In the URL being posted, you can see that it's adding a colon at the end of the URL (as though a port number might follow but there isn't one).

I don't think that's the issue per se. I checked the code and there appears to be no way to give it the access_token directly when logging in via password is disabled on server side (as it's using oauth).

@caronc Will this be implemented? For me it's currently pretty useless because it logins every time and gets new access token so two messages sent without a long break make only one of the message arrive because server throttles the login:

2024-01-17 14:13:18,176 [WARNING] apprise: Matrix server requested we throttle back 250.511ms; retries left 1.
2024-01-17 14:13:18,338 [WARNING] apprise: Matrix server requested we throttle back 250.349ms; retries left 0.
2024-01-17 14:17:28,853 [WARNING] apprise: Failed to handshake with Matrix server: Unauthorized - Invalid Token., error=403.

Logging by access token would solve this because it would do all the requests with the same access token so it wouldn't be throttled

Hey @uqlel,

You can increase rc_login Matrix rc_login documentation

I set:

  account:
    per_second: 5
    burst_count: 40

I still throttle sometimes but 2.5ms max instead of 250ms and it works for my use case.
Until an access token solution gets implemented it could work if you find a good value.

I had this throttle error but could not understand it was a login throttle and not a message throttle.

@uqlel : I'm trying to find a webhook standard for Matrix right now. One thing with webhooks is that it doesn't appear to support attachments. It seems to be a third party addon such as this, but upon googling, there are other formats as well.

What (Matrix) service are you specifically using if you don't mind me asking? Also if my interpretation above is really wrong, please correct me too! 🙂

I'm trying to find a webhook standard for Matrix right now.

Please see https://spec.matrix.org/v1.9/client-server-api/#authentication-types for how one could auth via token directly, and matrix-org/matrix-spec#541

Adding support for the m.login.registration_token (link) still looks like i need to authenticate with that (instead of a user/pass) to get a session id to work with. This process needs to be repeated for each use of Apprise (so the extra hit on the server).

Apprise keeps the session as long as it's instance is running. But calling it from the CLI or API, after the service has done it's deed, memory is freed and the session information is lost. I think this is what you're experiencing.

The only true solution will be for persistent storage (ticket here). Basically what you're looking for is After Apprise acquires your session, it holds onto it and re-uses it on future instances (saving the extra http request). The trade off of this is Apprise starts managing a small database which can grow, needs management, etc). When I do get around to adding persistent storage, this would be yet another use case for it.

Perhaps i should increase the throttle time (to adapt a little better and prevent clever workarounds like @jribal found)?

Adding support for the m.login.registration_token (link) still looks like i need to authenticate with that (instead of a user/pass) to get a session id to work with. This process needs to be repeated for each use of Apprise (so the extra hit on the server).

Please add instead support for direct m.login.token (link).
The registration token will not work if the Matrix server doesn't have direct registrations enabled and instead is SSO-only, which many are. Eg. let us give it the token to use, which we can generate out-of-band.

I'm not sure where we are with this ticket, persistent storage is in place and now the auth token acquired from the server is cached to disk (saving from constant logon and logoff calls). so this will drastically reduce the overhead. Not sure if I introduced any new problems with this new change yet or not.

I too wish to be able to login via the m.login.token
As above, I only allow SSO logins to Matrix, so username:password is not possible.

As an immediate workaround I'm simply using a 3rd party webhook bot.

I'm not sure where we are with this ticket, persistent storage is in place and now the auth token acquired from the server is cached to disk (saving from constant logon and logoff calls). so this will drastically reduce the overhead. Not sure if I introduced any new problems with this new change yet or not.

SSO is not supported, so we are unfortunately still nowhere.

https://github.com/caronc/apprise/blob/master/apprise/plugins/matrix.py#L878 => m.login.password which is NOT supported on most servers. It should allow to specify the access_token directly instead and use it via m.login.token.

Have a look at the recent PR and if someone could test it out, that woudl be great! Test instructoins are inside link. 🙏