go-irc / irc Goto Github PK

The main reason for this is that I strongly dislike importing this package as github.com/go-irc/irc/v2 and would like most of my tooling to recognize the import name properly. Additionally, I don't think this library is (currently) important enough for this to cause an issue in any packages other than mine. If you import from github.com/go-irc/irc this package will continue to work and as go module support is experimental, I don't have many qualms about temporarily breaking support.

Alternatively, if I could keep the current version tags and import this as github.com/go-irc/irc, that would be fine.

Related to #68. I plan on re-working tags and changing the module to the base path. As this library is not 100% stable, I plan on remapping the tags as follows:

v1.0.0 -> v0.1.0
v1.0.1 -> v0.1.1
v1.1.0 -> v0.1.2
v1.2.0 -> v0.1.3
v1.3.0 -> v0.1.4
v2.0.0 -> v0.2.0
v2.1.0 -> v0.2.1
v2.1.1 -> v0.2.2
v2.1.2 -> v0.2.3

Here are the current tags, for reference:

f5d8d856b31995567b637d6f8eaa78ae2e0f9206 refs/tags/v1.0.0
762af81012744b1461f57d414b82f3ae9a9c5b99 refs/tags/v1.0.1
f23d78362d188e111f34ce5db305cc53e7f1b932 refs/tags/v1.1.0
acbcebe1cd4c60fe20fd3a5a3d64accd53058f2e refs/tags/v1.2.0
a56998ff69437c015617474a7eaf3b0f6bb92b9e refs/tags/v1.3.0
01e72ff44254c3a85e6544295da4ce04be23c356 refs/tags/v2.0.0
29f1845f11cf8b48016865be7381299056393f72 refs/tags/v2.1.0
02e1ea193747d24d87b484473511ce0e4356946c refs/tags/v2.1.1
4901bf6be124ba1558d3657e91286393c97fb47f refs/tags/v2.1.2

This is made worse by #62 and so it should probably be fixed sooner rather than later.

See http://ircv3.net/specs/core/message-tags-3.2.html

This is exactly the same as accessing the map directly. What's the value-add of this method?

Hello,

I'm using this package for a side project, so first of all thank you for providing it!

I'd like to hack on my local copy and add the capability to call an arbitrary function on a recurring/scheduled basis (using e.g. time.Tickers) to do things like announce to channels and also to poll GPIO devices at regular intervals and present the results on IRC. But it's not immediately clear to me where would be the best place to add this. Would it be better...

1. Define a function similar to maybeStartPingLoop() and call it from RunContext()? or...
2. Edit the loop in startReadLoop() and call scheduled function calls there?

Or is there a better approach? I'm still kinda feeling my way around Go, coming from C#.

Thanks!

Docs

https://ircv3.net/specs/extensions/sasl-3.1.html
https://ircv3.net/specs/extensions/sasl-3.2.html

Current Issues (And Possible Solutions)

There's no way to hook into the registration process. The way we handle CAP negotiation should be made more generic (hopefully so there's an extensible way to ensure something happens before registration), we should add a method of handling SASL auth before registration is done, and we should possibly expose the pre-registration system to the user.

Just wanted to make an issue here for some clarification, when using this library and running

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()

//IRC CONFIG CODE HERE
client := irc.NewClient(conn, config)
err = client.RunContext(ctx)

if err != nil {
	log.Fatalln(err)
	panic(err)
}

The irc client doesn't cancel or close after the 3 seconds given to the context. Sorry if this is a dumb question I'm still fairly new to go contexts!

Thank you so much for the library, really been enjoying it.

Just as a sidenote, when I added the following code to client.go it exits the IRC client after the allotted time as expected.

	var err error
	select {
	case err = <-c.errChan:
	case <-ctx.Done():
		wg.Done()
	}

A readme would be nice to have.

f252a88 is a breaking change. This breaks builds.

It would be nice if there was an embedded root handler in the Client object. With the rewrite in pr #10, handlers temporarily won't be a thing.

It's commented because the origin is "Charybdis/Atheme, IRCv3". Maybe print_specific should parse the comma-separated list of origins?

Currently irc.Event has a number of duplicated fields.

Event.Prefix is the same as Event.Identity.Raw. You can even infer the Event.Prefix from Event.Identity.

I would like to remove Event.Identity and replace it with Event.SplitPrefix() (nick, user, host string)

Any comments, or ideas on how to make this better? This does have the unfortunate side effect of possibly requiring the parsing of Event.Prefix multiple times, though I don't think that should be a huge issue.

I wasn't aware this existed - ircdocs/modern-irc#137

This should allow spaces and a few other characters in ISUPPORT values.

Hello all!

I've been looking at releasing v4 of this library, mostly as a slightly simpler version and splitting some utilities I keep having to make out into a separate ircx package. I wanted to run all these past people before I just go ahead and do them though.

• Move client out to ircx - the idea is to keep the base package to only protocol-related tools like reading and writing messages, numerics, etc.
• Change the import path to gopkg.in/go-irc/irc.v4 - this will allow us to also have gopkg.in/go-irc/ircx.v0 rather than gopkg.in/irc.v4 and the longer form for ircx
• Taking a look at better context support for Conn. Potentially seeing if there's a good way to handle a Write with a timeout.

Additional tools meant for ircx:

• Client - I have some ideas for better Context support
• ISupport parsing/tools
• Some form of tracker which allows you to track which channels you're in, what their topics are, and what nicks are in each channel. I could potentially add user mode tracking as well.

Does anyone have any thoughts?

As an example in girc-go, a TagValue is a *string so it can be nil if there's no value.

Hi @belak,

I am starting to use your library and I noticed that an example is missing.

I am on my way trying to understand how it works :)

Here are the current tags:

f5d8d856b31995567b637d6f8eaa78ae2e0f9206 refs/tags/v1.0.0
762af81012744b1461f57d414b82f3ae9a9c5b99 refs/tags/v1.0.1
f23d78362d188e111f34ce5db305cc53e7f1b932 refs/tags/v1.1.0
acbcebe1cd4c60fe20fd3a5a3d64accd53058f2e refs/tags/v1.2.0
a56998ff69437c015617474a7eaf3b0f6bb92b9e refs/tags/v1.3.0
01e72ff44254c3a85e6544295da4ce04be23c356 refs/tags/v2.0.0
29f1845f11cf8b48016865be7381299056393f72 refs/tags/v2.1.0
02e1ea193747d24d87b484473511ce0e4356946c refs/tags/v2.1.1

I really hate to do this, but I haven't been able to get vgo to recognize the fact that there is a v2 version of go-irc, so to work around it I'm going to be resetting these tags so v1.0.0 will become v0.1.0, v1.0.1 will become v0.1.1, v1.1.0 will become v0.2.0 etc. I really do apologize to anyone who runs into this, but I don't currently have a better workaround.

Currently handlers are only used to sort input. It would be nice to be able to handle output as well for preprocessing and hooks. It would make the lib act more like a middleware lib.

Perhaps a way of registering middleware and depending on what it implements, running it at different times?

It's here: https://github.com/go-irc/irc/blob/master/utils/numerics.yml#L2379

I wonder if it's just missing "IRCv3" in the origin field? Where's the upstream for numerics.yml, should we fix it there?

Filed by belak in #encoded

Our debugging support is very bad. We should be logging all kinds of interaction throughout the lib, but we don't. Let's fix that.

Perhaps using something like glog or logrus

Would you consider dropping the TagValue type so that the Tags type can just be map[string]string? That would avoid unnecessary conversions between TagValue and string when accessing or updating tags.

Right now we just append _ to the end of the nick.

Hi, first of all, thank you for the library. I'm not sure if this is the right place for this.
I wrote an xdcc command line tool (based on this package) which allows to search and retrieve irc files in a user friendly way:
https://github.com/ostafen/xdcc-cli

I would appreciate if you could add a link to my client in a section reporting all the projects related to your IRC package.
Thank you in advance

Right now, .Bytes() doesn't handle an empty final parameter properly. A : needs to come before an empty trailing argument.

func CasemapRFC1459(name string) string
func CasemapRFC1459Strict(name string) string
func CasemapRFC7613(name string) string
func CasemapASCII(name string) string

These would be useful for external clients and for doing things properly in the v4 Tracker types.

Hi,

I've got a tiny package here https://github.com/qaisjp/go-discord-irc/tree/master/irc/format which deals with irc text formatting.

The code is essentially ported from the following Node packages:

• https://www.npmjs.com/package/irc-formatting
• https://github.com/reactiflux/discord-irc/blob/87a3458bdde48290960405f2bf0cf53b7ff17b5e/lib/formatting.js#L25

I'm currently fleshing it out a bit more to abide by the @DanielOaks's IRC formatting living specification and to clean it up a little bit / add tests.

I have not been able to find another package that provides the same functionality, so when I'm done, would you be open to me submitting a pull request to move that content into this repo or under the go-irc org?

p.s. I welcome all feedback on that package / will of course be happy to make any changes required for inclusion in this org.

I've been making a lot of breaking changes. It would be nice for anyone who actually wants to use this to have a more stable base.

This is the list of things I'd like to do for 2.0

• Remove Message.FromChannel as we have a more accurate version on the client. This does mean you won't be able to use it if you've only got a Conn.