5 ms·

Show HN: Jackal – XMPP server in Go

91 points by ortuman 8y ago

sofaofthedamned 8y ago
I've just checked the Docker image and it's 417mb. How on earth is it this large? https://hub.docker.com/r/ortuman/jackal/tags/ https://hub.docker.com/r/ortuman/jackal/tags/
- r_venkat 8y ago
  The image seems to have the code and dependencies copied into it+ `go build` run on it, instead of just copying the built artifact.
  - ihsw2 8y ago
    This is an opportunity for enterprising OSS contributors -- by virtue of being written in Go, converting their current Dockerfile to one that uses multi-stage builds should be simple and the resulting image would be as minimal as they come.
    - SEJeff 8y ago
      Example golang multi-stage build: https://github.com/jaegertracing/jaeger/blob/master/cmd/query/Dockerfile https://github.com/jaegertracing/jaeger/blob/master/cmd/quer...
      - Boulth 8y ago
        With the caveat that it doesn't build the app inside container, so the multi stage build is kind of underutilized here.
        e12e 8y ago
        You almost certainly want to build the app inside a container, but probably not the same container that result from the build. [ed: well maybe not for a simple go project, as go has great cross compilation support. But if there's a bit of Javascript/(s)css/static resource munging - a container with a predictable build environment might become appealing. ]
        Boulth 8y ago
        Isn't this the purpose of multi stage builds? To have one stage for building it and another, from scratch, to run it?
        SEJeff 8y ago
        It is one of the purposes, yes. The idea being that you don't need build artifacts in containers which run the application.
- true_religion 8y ago
  It probably bakes in the dependencies. I do that on CI as well, since building dependencies often takes longer than just downloading a full VM.
- eximius 8y ago
  Why is it even using Docker at all? One of the features of Go is that it is statically linked with it's dependencies!?
  - kiliankoe 8y ago
    Docker has a few more upsides than just bundling an app with its dependencies, orchestration being one of them. Also, a go app wouldn't have to be cross-compiled for whatever architecture as long as Docker runs there. Go makes that easy and effortless, sure, and there's nothing stopping you from doing so.
    - chatmasta 8y ago
      Docker containers inherit the architecture of the host system. There is no CPU virtualization involved. So you still need to cross compile if you want to run the binary on another architecture, regardless of whether or not the binary is running inside a docker container.
- mike-cardwell 8y ago
  I just downloaded the image it's based from "golang:1.10" according to the Dockerfile - https://github.com/ortuman/jackal/blob/master/Dockerfile https://github.com/ortuman/jackal/blob/master/Dockerfile mike@ung:~$ sudo docker image ls|grep golang golang 1.10 6b369f7eed80 3 days ago 794MB mike@ung:~$ 794MB... Should probably base it off an Alpine image instead. Would make it many times smaller. [edit] In fact, there is a "golang:1.10-alpine" Docker image: mike@ung:~$ sudo docker image ls|grep alpine golang 1.10-alpine 05fe62871090 4 days ago 376MB mike@ung:~$ Hmm. even that one is bigger than I expected.
  - unfunco 8y ago
    FROM scratch ADD main / CMD ["/main"]
Boulth 8y ago
This is really interesting. As far as I know there are only two servers that power the majority of public instances and both of them have weak type systems.
- lucian1900 8y ago
  Go's is not much stronger either. It hardly makes any difference.
  - Thaxll 8y ago
    You don't known what you're talking about, did you even bother search interface {} in the code?
    - erik_seaberg 8y ago
      Here are methods that store and retrieve … something, probably. The author had to make up method names because map[string]interface{} doesn't have an interface we could satisfy. func (ctx *Context) SetObject(object interface{}, key string) { … } func (ctx *Context) Object(key string) interface{} { … } Here a caller has to provide a method that takes an arbitrary number of … whatever. type rowScanner interface { Scan(...interface{}) error }
  - icholy 8y ago
    Keep telling yourself that
- kiliankoe 8y ago
  I assume you're referring to ejabberd (erlang) and prosody (lua)?
  - Boulth 8y ago
    Yes.
- funkaster 8y ago
JepZ 8y ago
Nice to see someone actually starting a Go powered XMPP server. I hope their breath is long enough to bring it to a competitive state.
0xdeadbeefbabe 8y ago
It's good to see something written in go.
orivej 8y ago
The principal feature that I consider when evaluating XMPP servers and clients is their support for reliable message delivery (no message loss on connection interruptions), and the main method of achieving it is with XEP-0198 ("Stream Management") [1]. Unfortunately Jackal does not support it, and AFAIK it is much harder to implement it for an existing server or client than to design the application with XEP-0198 in mind. To support reliable message delivery as defined in XEP-0198, the application needs to: (1) count and acknowledge stanzas; (2) buffer unacknowledged stanzas for redelivery in case of stream resumption; (3) resend delayed stanzas in case of stream not being resumed. Note that some clients that claim support for XEP-0198 implement `urn:xmpp:sm:3` (Psi+, Conversations, Gajim with python-nbxmpp>=0.5.6), while others implement `urn:xmpp:sm:2` (Swift, Gajim with python-nbxmpp<0.5.6). The revisions differ in how they count stanzas. Ejabberd supports them both simultaneously. The level of support also varies. An application may: (1) just count and acknowledge stanzas; (2) resend stanzas on stream resumption; (3) resend stanzas on reconnect without stream resumption; (4) resend stanzas after the application is restared. Psi+ supports 1 and 2, does not support 4, and probably does not support 3. Swift supports only 1. [2] [1] It is also technically possible for the client to use XEP-0313 ("Message Archive Management") to retrieve undelivered messages and to discover and resend unsent messages, but the latter is not described in the XEP, and I'm not aware of the clients that do so. I have found this suggested by Holger Weiß at https://github.com/redsolution/xabber-android/issues/128#issuecomment-142424907 https://github.com/redsolution/xabber-android/issues/128#iss... , together with a clever (currently abandoned) extension of XEP-0313 with `urn:xmpp:mam:sub` that subsumes XEP-0280 ("Message Carbons"). [2] To study interactions between Jabber clients and servers, I wrote https://github.com/orivej/xmpp-logging-proxy https://github.com/orivej/xmpp-logging-proxy that serves as a Jabber server by relaying communications to the actual Jabber server while saving the decrypted streams to files.
- defanor 8y ago
  I agree: not to discourage OP, but there is plenty of XMPP implementations (as well as those for other protocols), yet very few complete (say, in the XEP-0387 sense) ones, and even fewer reusable (libraries providing C interface, or something else more or less common and standard) ones. It seems that it would be more useful to put time/effort into improving those, unless there are really good reasons for making new ones.

91 points by ortuman 8y ago

I've just checked the Docker image and it's 417mb. How on earth is it this large? https://hub.docker.com/r/ortuman/jackal/tags/ https://hub.docker.com/r/ortuman/jackal/tags/

r_venkat 8y ago
The image seems to have the code and dependencies copied into it+ `go build` run on it, instead of just copying the built artifact.
- ihsw2 8y ago
  This is an opportunity for enterprising OSS contributors -- by virtue of being written in Go, converting their current Dockerfile to one that uses multi-stage builds should be simple and the resulting image would be as minimal as they come.
  - SEJeff 8y ago
    Example golang multi-stage build: https://github.com/jaegertracing/jaeger/blob/master/cmd/query/Dockerfile https://github.com/jaegertracing/jaeger/blob/master/cmd/quer...
    - Boulth 8y ago
      With the caveat that it doesn't build the app inside container, so the multi stage build is kind of underutilized here.
      - e12e 8y ago
        You almost certainly want to build the app inside a container, but probably not the same container that result from the build. [ed: well maybe not for a simple go project, as go has great cross compilation support. But if there's a bit of Javascript/(s)css/static resource munging - a container with a predictable build environment might become appealing. ]
        Boulth 8y ago
        Isn't this the purpose of multi stage builds? To have one stage for building it and another, from scratch, to run it?
        SEJeff 8y ago
        It is one of the purposes, yes. The idea being that you don't need build artifacts in containers which run the application.
true_religion 8y ago
It probably bakes in the dependencies. I do that on CI as well, since building dependencies often takes longer than just downloading a full VM.
eximius 8y ago
Why is it even using Docker at all? One of the features of Go is that it is statically linked with it's dependencies!?
- kiliankoe 8y ago
  Docker has a few more upsides than just bundling an app with its dependencies, orchestration being one of them. Also, a go app wouldn't have to be cross-compiled for whatever architecture as long as Docker runs there. Go makes that easy and effortless, sure, and there's nothing stopping you from doing so.
  - chatmasta 8y ago
    Docker containers inherit the architecture of the host system. There is no CPU virtualization involved. So you still need to cross compile if you want to run the binary on another architecture, regardless of whether or not the binary is running inside a docker container.
mike-cardwell 8y ago
I just downloaded the image it's based from "golang:1.10" according to the Dockerfile - https://github.com/ortuman/jackal/blob/master/Dockerfile https://github.com/ortuman/jackal/blob/master/Dockerfile mike@ung:~$ sudo docker image ls|grep golang golang 1.10 6b369f7eed80 3 days ago 794MB mike@ung:~$ 794MB... Should probably base it off an Alpine image instead. Would make it many times smaller. [edit] In fact, there is a "golang:1.10-alpine" Docker image: mike@ung:~$ sudo docker image ls|grep alpine golang 1.10-alpine 05fe62871090 4 days ago 376MB mike@ung:~$ Hmm. even that one is bigger than I expected.
- unfunco 8y ago
  FROM scratch ADD main / CMD ["/main"]

Boulth 8y ago

This is really interesting. As far as I know there are only two servers that power the majority of public instances and both of them have weak type systems.

lucian1900 8y ago
Go's is not much stronger either. It hardly makes any difference.
- Thaxll 8y ago
  You don't known what you're talking about, did you even bother search interface {} in the code?
  - erik_seaberg 8y ago
    Here are methods that store and retrieve … something, probably. The author had to make up method names because map[string]interface{} doesn't have an interface we could satisfy. func (ctx *Context) SetObject(object interface{}, key string) { … } func (ctx *Context) Object(key string) interface{} { … } Here a caller has to provide a method that takes an arbitrary number of … whatever. type rowScanner interface { Scan(...interface{}) error }
- icholy 8y ago
  Keep telling yourself that
kiliankoe 8y ago
I assume you're referring to ejabberd (erlang) and prosody (lua)?
- Boulth 8y ago
  Yes.
funkaster 8y ago

JepZ 8y ago

Nice to see someone actually starting a Go powered XMPP server. I hope their breath is long enough to bring it to a competitive state.

0xdeadbeefbabe 8y ago

It's good to see something written in go.

orivej 8y ago

The principal feature that I consider when evaluating XMPP servers and clients is their support for reliable message delivery (no message loss on connection interruptions), and the main method of achieving it is with XEP-0198 ("Stream Management") [1]. Unfortunately Jackal does not support it, and AFAIK it is much harder to implement it for an existing server or client than to design the application with XEP-0198 in mind. To support reliable message delivery as defined in XEP-0198, the application needs to: (1) count and acknowledge stanzas; (2) buffer unacknowledged stanzas for redelivery in case of stream resumption; (3) resend delayed stanzas in case of stream not being resumed. Note that some clients that claim support for XEP-0198 implement `urn:xmpp:sm:3` (Psi+, Conversations, Gajim with python-nbxmpp>=0.5.6), while others implement `urn:xmpp:sm:2` (Swift, Gajim with python-nbxmpp<0.5.6). The revisions differ in how they count stanzas. Ejabberd supports them both simultaneously. The level of support also varies. An application may: (1) just count and acknowledge stanzas; (2) resend stanzas on stream resumption; (3) resend stanzas on reconnect without stream resumption; (4) resend stanzas after the application is restared. Psi+ supports 1 and 2, does not support 4, and probably does not support 3. Swift supports only 1. [2] [1] It is also technically possible for the client to use XEP-0313 ("Message Archive Management") to retrieve undelivered messages and to discover and resend unsent messages, but the latter is not described in the XEP, and I'm not aware of the clients that do so. I have found this suggested by Holger Weiß at https://github.com/redsolution/xabber-android/issues/128#issuecomment-142424907 https://github.com/redsolution/xabber-android/issues/128#iss... , together with a clever (currently abandoned) extension of XEP-0313 with `urn:xmpp:mam:sub` that subsumes XEP-0280 ("Message Carbons"). [2] To study interactions between Jabber clients and servers, I wrote https://github.com/orivej/xmpp-logging-proxy https://github.com/orivej/xmpp-logging-proxy that serves as a Jabber server by relaying communications to the actual Jabber server while saving the decrypted streams to files.

defanor 8y ago
I agree: not to discourage OP, but there is plenty of XMPP implementations (as well as those for other protocols), yet very few complete (say, in the XEP-0387 sense) ones, and even fewer reusable (libraries providing C interface, or something else more or less common and standard) ones. It seems that it would be more useful to put time/effort into improving those, unless there are really good reasons for making new ones.