fluuxio / go-xmpp Goto Github PK

It makes it possible to send stanza when the client is connected (presence, join room, etc).

This is also related to cache of server features (see #34)

Does not handle IPv6 correct

This is a follow up of #94

The goal is to be able to use a command-line tool to allow sending message to XMPP user or MUC, for easy notification automation.

Currently, the developer has to make his own dispatcher code in each client or component.

It would be more handy to provide the needed infrastructure to let the developer match the packet they are interested to handle in their code.

It also likely mean that it will way packets are received, moving from a channel iterator to a set of callback functions. Developers can always get back to the channel behaviour by sending the message on a channel in their callbacks.

It could be inspired by https://github.com/agl/xmpp-client

The JID class needs to split on the resourcepart first and be more careful about how it's splitting. Eg. trying to parse the following valid JID will cause a panic: [email protected]/resource@moreresource/stillmoreresourcepart

Disclaimer: Shameless self promotion follows. Feel free to steal code from my implementation here. I'd love to collaborate and reduce code duplication on some of this. I also have an issue at golang/go#13797 to add JIDs into the x/net package. No idea if that will be accepted or not though.

EDIT: I just noticed that there's a test to make sure that [email protected]/test/test is invalid, but this is a perfectly valid JID. Not sure if this was deliberate or not.

This is handy for example for logging such traffic.

I need to test / validate this, but possibly an empty route as last route, would do that.
Even in that case, it is probably best to add an explicit alias in the router API to clarify developer intent.

See discussion here: #55 (comment)

We need to check client Send and SendRaw.

IQ code has a pretty slick way of registering a struct into which an IQ payload should be unmarshaled using reflect package's TypeOf.

Unfortunately, all types are hardcoded.

It would be a nice way to send custom, currently unsupported payloads (e.g. User Activity for PEP) if the library would allow registering new types into the type registry.

Would it make sense to create such a public API?

Is joining a MUC implemented in this library?

I looked around and found a few issues mentioning MUC that seem to indicate it is implemented, but I can't find any documentation on how to actually use it.

Could you point me in the right direction? Thanks!

For now, the value is hardcoded and warns about the expiration 48 hours before expiration.

For example, we should not retry connection if jid is badly formatted or if credentials are invalid.

It should of course not be done in production, as it opens the risk of man-in-the-middle attacks.
However, some developers like to be able to use self-signed certificates.

This relates to #87

We should allow sending messages for a while, until we reconnect. The send would fail on messages with an error when the queue is full.

We should also link that to stream management ack to keep outgoing message in that queue until they have been acked by the server, so that they can be replayed if they are lost.

I found my old code again ... yaja- most of the handling is a little bit trash.

But the library of structs is still not bad (here: xmpp)

The parsing is really easy: https://dev.sum7.eu/genofire/yaja/blob/master/client/comm.go#L9-37.

Another nice feature is, that it is not necessary to iterate over all Message.Extensions we could just make a if PresenceClient.MUC !=nil because omitempty pointer are filled with nil if the values for this structs are not given.

atm i miss somethings to replace other libraries in related project:

• muc support
• obb (to publish image urls as http_upload)
• html body

We can thus simplify IQ. IQ can only have a single payload + an optional error.

"An IQ stanza of type "get" or "set" MUST contain exactly one
child element, which specifies the semantics of the particular
request."

First thank you for this library and the echo bot example. I was able to build a simple bot without programming experience following the example, although I have to admit at the start I used code from this repo.

But despite reading in the library a lot it is still not clear to me how I could check whether the connection is still alive. My bot works pretty well till it stops working due to a network flaw/reconnect. Could you please give me a hint at which modules/functions I should have a closer look?

We reply with an error not-implemented stanza.

Here is an example stanza error:

<iq from="service.localhost" type="error" to="test1@localhost/mremond-mbp" id="1" >
 <error type="cancel" code="501" >
  <feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
 </error>
 <query xmlns="unknown:ns"/>
</iq>

There is no way to close session or client connection.

The godocs have been down for a handful of weeks now:

Any ideas on what is causing it/how to fix it?

The see-other-host stream level directive is used by a server to instruct a client to reconnect on another host. It is for example used when a node in a cluster is shutting down for maintenance operations.

Reference: https://tools.ietf.org/html/rfc6120#section-4.9.3.19

Hi,

I am trying to log in, query PEP node for user activity (xep-0108), publish something on this node, disconnect and shut down.

I would prefer to minimize the notifications to other users, I would prefer to minimize the traffic, and therefore I don't need or wish to publish presence or receive presences. Publishing a presence would encourage clients to do other communications with the PEP publisher.

Could you add an option to sign in without sending <presence/>? There is already a comment wondering exactly whether this should happen. I believe no, there should not be auto-sent <presence/>; and if yes, it should be configurable what the presence contains (capabilities, status type, status text, ...).

Perhaps the default shouldn't change to avoid breaking existing clients, but it should be possible to switch the sending off.

Currently, building a stanza can lead to quite lengthy code, like the following:

iqResp := xmpp.NewIQ(xmpp.Attrs{Type: "result", From: iq.To, To: iq.From, Id: iq.Id, Lang: "en"})
identity := xmpp.Identity{
	Name:     opts.Name,
	Category: opts.Category,
	Type:     opts.Type,
}
payload := xmpp.DiscoInfo{
	XMLName: xml.Name{
		Space: xmpp.NSDiscoInfo,
		Local: "query",
	},
	Identity: identity,
	Features: []xmpp.Feature{
		{Var: xmpp.NSDiscoInfo},
		{Var: xmpp.NSDiscoItems},
		{Var: "jabber:iq:version"},
		{Var: "urn:xmpp:delegation:1"},
	},
}
iqResp.Payload = &payload

I am exploring ways to make the code more compact and more guided through helpers (usable with code completin) with a code like this:

b := stanza.NewBuilder().Lang("fr") // Create builder and set default language

iq := b.IQ(stanza.Attrs{Type: "get", To: "service.localhost", Id: "disco-get-1"})

payload := b.DiscoInfo()
identity := b.Identity("Test Component", "gateway", "service")
payload.SetFeatures(stanza.NSDiscoInfo, stanza.NSDiscoItems, "jabber:iq:version", "urn:xmpp:delegation:1").
	SetIdentities(identity)

iq.Payload = payload

What do you think?

The workaround PostConnect works nice.
But there should not be crashed, if connect is not already established.

Client manager should be able to handle reconnect and exponential back-off on both client connection and component connection.

It means that you have another client with the same resource name that has kicked your session. If you reconnect, you will end up stuck in a ping pong loop.

When creating tls connection the domain should be the connection address not JID domain part. there might be situation where connection is made to xmpp.example.com and jids are @example.com. this causes the tls fail.

Any Idea how to support it?
https://xmpp.org/extensions/xep-0184.html

Maybe by adding in Message:

	// Any hasn't matched element
	Other []XMLElement `xml:",any"`

See https://xmpp.org/extensions/xep-0071.html

This relates to #29

Server certificate is expired.

$ go get fluux.io/xmpp
package fluux.io/xmpp: unrecognized import path "fluux.io/xmpp" (https fetch: Get https://fluux.io/xmpp?go-get=1: x509: certificate has expired or is not yet valid)

This is a feature described in XEP-0355 - Namespace Delegation: https://xmpp.org/extensions/xep-0355.html

It means the component should fully handle the discovery (info, items, identities, features), but the developer should be allowed to override that default behaviour.

I got the warning:
call of xmpp.NewClient copies lock value: gosrc.io/xmpp.Config contains crypto/tls.Config contains sync.Once contains sync.Mutexcopylocks
I think that TLSConfig option in Config should be pointer.

We need to use whitespace ping to maintain the connection and basically "ask" the network layer if the connection is still valid.
It should also solve #8.

I will not support XMPP ping for now as it is much more consuming for both the client and the server (CPU and bandwidth) without providing any significant benefit for checking the client to server connection. XMPP ping should be limited to client to client and components interactions.

go-cmp library is used for testing.