This patch prevents a panic when a register request is unauthorised.

Example stacktrace produced when attempting to register a user with an invalid access token:

Request panicked!
goroutine 15490878 [running]:
runtime/debug.Stack(0xc421596550, 0xc4216455f0, 0xc4215965f0)
\t/usr/local/go/src/runtime/debug/stack.go:24 +0x79
github.com/matrix-org/util.Protect.func1.1(0xc4208f0800, 0xbd33a0, 0xc42198e380)
\t/home/scalar-staging/scalar/vendor/src/github.com/matrix-org/util/json.go:87 +0x14c
panic(0x8eb4e0, 0xbf8bf0)
\t/usr/local/go/src/runtime/panic.go:489 +0x2cf
github.com/matrix-org/scalar/bots/integrator.(*PersonalBotAPI).RegisterBot(0xc420075ad0, 0xc420325f80, 0x2e, 0xc420325f80, 0x2e)
\t/home/scalar-staging/scalar/src/github.com/matrix-org/scalar/bots/integrator/personalbot.go:66 +0x85e
github.com/matrix-org/scalar/bots/integrations/rssbot.(*RSSBot).configureService(0xc420075ad0, 0xc4208f0900, 0xc4207c6780, 0x12, 0x1, 0x0, 0x0, 0x0)
\t/home/scalar-staging/scalar/src/github.com/matrix-org/scalar/bots/integrations/rssbot/rssbot.go:119 +0x324
github.com/matrix-org/scalar/bots/integrations/rssbot.(*RSSBot).OnIncomingRequest(0xc420075ad0, 0xc4208f0900, 0xc4207c6780, 0x12, 0x0, 0xc4210ae380, 0xc4208f0900, 0xc4217382f0)
\t/home/scalar-staging/scalar/src/github.com/matrix-org/scalar/bots/integrations/rssbot/rssbot.go:71 +0x128
github.com/matrix-org/scalar/bots/integrator.APIWrapper.OnIncomingRequest(0xbd4220, 0xc420075ad0, 0xc4208f0900, 0x97dcd8, 0x9, 0xc4217382f0, 0xc)
\t/home/scalar-staging/scalar/src/github.com/matrix-org/scalar/bots/integrator/integrator.go:45 +0x21c
github.com/matrix-org/scalar/bots/integrator.(*APIWrapper).OnIncomingRequest(0xc420481480, 0xc4208f0900, 0xc074e0, 0xc420d7f655, 0xc4217f1bb0, 0x42b25e)
\t<autogenerated>:5 +0x60
github.com/matrix-org/util.MakeJSONAPI.func1(0xbd33a0, 0xc42198e380, 0xc4208f0900)
\t/home/scalar-staging/scalar/vendor/src/github.com/matrix-org/util/json.go:128 +0x7b
github.com/matrix-org/util.Protect.func1(0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/home/scalar-staging/scalar/vendor/src/github.com/matrix-org/util/json.go:92 +0x8b
github.com/matrix-org/util.WithCORSOptions.func1(0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/home/scalar-staging/scalar/vendor/src/github.com/matrix-org/util/json.go:171 +0x59
main.removeAPIPrefix.func1(0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/home/scalar-staging/scalar/src/github.com/matrix-org/scalar/cmd/scalar/scalar.go:132 +0x13b
net/http.HandlerFunc.ServeHTTP(0xc4204814d0, 0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/usr/local/go/src/net/http/server.go:1942 +0x44
net/http.(*ServeMux).ServeHTTP(0xc074e0, 0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/usr/local/go/src/net/http/server.go:2238 +0x130
net/http.serverHandler.ServeHTTP(0xc42043a2c0, 0xbd33a0, 0xc42198e380, 0xc4208f0800)
\t/usr/local/go/src/net/http/server.go:2568 +0x92
net/http.(*conn).serve(0xc420b98460, 0xbd3da0, 0xc4210ae240)
\t/usr/local/go/src/net/http/server.go:1825 +0x612
created by net/http.(*Server).Serve
\t/usr/local/go/src/net/http/server.go:2668 +0x2ce
" context=missing panic="runtime error: invalid memory address or nil pointer dereference"

Hi,

I'm trying to build an IOU bot for matrix (https://github.com/dryvenn/matrix-iou-bot) and I was wondering:

• How do I get a user's "display name" from his ID?

• How do I get the list of all the users in a room?

The goal here is to map human-friendly names in a message to actual users.

Any help appreciated!

Hi there,

what's the current state of this project? Do you have a meaningful roadmap? Versioning and tags related to the specs?

Since the godocs refer to Client Server API r0.2.0, I'm very reluctant to use this lib for a new project. Instead, I'm seriously thinking about generating an API client based on the provided swagger definitions and go-swagger.

The current method, for its HTTP client, allocates a byte array, marshaled into the byte array, and then wraps that into a byte buffer. Similarly, the entire HTTP Response body is read into memory, then unmarshaled, and then parsed. This might become an issue because of excessive memory if there's a large amount of JSON being received from any particular Matrix server, so this PR skips a few steps and uses the encoding/json NewEncoder() to encode the interface directly to a byte buffer, and NewDecoder() for the io.ReadCloser from the response. This lowers memory usage and any unnecessary swapping.

Downside to this is that the contents of the JSON file cannot be passed via return variable, though I'm not sure the value in returning the contents with a 2XX response, if it is being unmarshaled anyway? In lieu of this, if it isn't a 2XX response, then the contents will be read into memory, as the amount of memory needed is low for returned errors, and included in the HTTPError struct. As a consequence, it becomes a breaking change for any applications that rely on the MakeRequest function.

Currently the CI uses Go 1.8, which isn't supported by some linters anymore, and also makes some calls to Go's tool suite which aren't supported anymore. This looks like a trivial thing to do, just needs to be done.

Is the scope of this project just targeting r0.2.0? I'm currently writing a bot using this library. I have no problem updating this library as I go, and submitting sensible PRs. But what's the scope?

Can we tag the master as "Matrix Spec r0.2.0" and let master move forward as "unstable"?

Or is that already the scope of this project?

• Client.Login

  • Accept Identifier

• Client.Logout

  • No Changes

• Client.LogoutAll

  • Initial implementation

~This also adds a go.mod file. I hope this is wanted.~

A bot I'm building needs to be able to set the filename for files uploaded to the content repo. Without these changes the download returns a file with the mediaid as filename and no extension.

This should now be the correct way to do it.

I've added ThumbnailURL and ThumbnailInfo to the ImageMessage struct so Thumbnails can be added, which is important for e.g. mobile clients.

While at it, I've also added strucs for other message types, in case someone needs them, like I needed the thumbnails.

Finally, I've added some comments on what information in what unit a field should contain, if it's not obvious. (e.g. Mastodon has a field "size" in its imageInfo which contains a string like "WxH" )

Leave events are currently unhandled by the SDK.

It is useful for bots to have access to leave events so that they can clean up state etc. after having been kicked from a room.

@Kegsay can you please have a look at the following and let me know if it makes sense (specifically sync.go L78, using the timeline events in this way)? Thanks.

Adds:

// SendFormattedText sends an m.room.message event into the given room with a msgtype of m.text, supports a subset of HTML for formatting.
// See https://matrix.org/docs/spec/client_server/r0.6.0#m-text
func (cli *Client) SendFormattedText(roomID, text, formattedText string) (*RespSendEvent, error) {

Example Request send empty JSON in Request Body,but Mark Read method send nothing in Request Body. See https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-rooms-roomid-receipt-receipttype-eventid

Can you create a release for this project and follow semantic versioning please? It is ok to start with v0 version to allow backward incompatible changes. So v0.1.0 could be a good start.

This will allow users to pin specific version instead of commit hash and setup auto-updating (e.g. Dependabot).

Thanks!

I just discovered HTMLMessage, and it's not clear why it exists in this form to me. I discovered it by looking at #58, and noticed that my PR #82 seems to more naturally integrate. I don't agree with automatically shaping the HTML (what if a user sends <span> with formatting? Now you have something like <span><span></span>, what part's the body? Admittingly, I don't follow the regex there, though), I don't even agree simply with calling it HTML in a public type as it's merely a subset of HTML, it's just formatted text. Rather I think we should make it clear it's a subset, and link to where the differences are found.

I don't think someone receiving or sending formatted text using this library is going to commonly think to look for HTMLMessage, which doesn't seem to be connected to anything, just an oddity. I think SendFormattedText, linked to the spec where it was inspired (what my PR effectively is) is a lot more natural, and fits nicely along-side SendText, we can also re-use the struct there, as that part of the spec was simply extended, we can simply extend the struct, without breaking backward compatibility (unless someone didn't name their fields while declaring, which is considered bad practice anyways).

I think we should have something more natural, and I say this because it is still just text lol. It's all grouped together in the spec, why split it up in the library? :)

In short: HTMLMessage is very confusing as-is, and seems to break the library's flow. Let's look at the intent behind it, and implement it better.