profile
viewpoint
Hubert Hirtz hhirtz France Lightweight, simple and fast HTTP programmer

hhirtz/ellidri 7

Your kawaii IRC server

hhirtz/randomfeh 1

Wallpaper slideshows with feh and swaybg

hhirtz/block-ciphers 0

Collection of block cipher algorithms written in pure Rust

hhirtz/gimli 0

A blazing fast library for consuming the DWARF debugging format

hhirtz/harfbuzz_rs 0

A fully safe Rust wrapper for the harfbuzz text shaping library.

hhirtz/libfabric 0

Open Fabric Interfaces

hhirtz/linenoise 0

A small self-contained alternative to readline and libedit

hhirtz/mercury 0

Mercury is a C library for implementing RPC, optimized for HPC.

hhirtz/modern-irc 0

A useful overview and reference to the IRC client protocol as it is implemented today.

hhirtz/NewPipe 0

A libre lightweight streaming front-end for Android.

fork hhirtz/gimli

A blazing fast library for consuming the DWARF debugging format

https://docs.rs/gimli/

fork in 4 days

pull request commentspack/spack

Improvements to building "cargo" packages

The timing for dependency vendoring does not allow patches on the cargo manifest: cargo vendor is called in the stage phase before any patch can be applied.

I looked into it for a bit and there doesn't seem to be a trivial fix for this (very new to spack, so i could be wrong :). In this case this should be documented with CargoPackage (or if possible make patch() raise an error when called in this class), otherwise it will lead to weird bugs due to cargo using the unpatched manifest.

Example:



[target.'cfg(windows)'.dependencies]
unused-arch-specific-dep = { path = "../non-existent-dir" }
AndrewGaspar

comment created time in 13 days

pull request commentircv3/ircv3-specifications

Add the CHATHISTORY extension specification - refactored

Here are other implementations (not fully compliant though):

[0] https://todo.sr.ht/~emersion/soju/12

prawnsalad

comment created time in 23 days

pull request commentspack/spack

Improvements to building "cargo" packages

Hi Andrew!

Thank you very much for this PR. I tested the installation of ripgrep without internet (from a local spack mirror), and it works! I'll test it with a library that exports a C interface and come back with the results (there isn't one in spack's builtin repo already is there?)

Rust libraries (with a rust interface) can be made available in a local cargo registry [0], so that cargo manifests and build commands don't have to be changed to work without internet. Then spack shouldn't be needed for this use-case.

[0] https://github.com/ChrisGreenaway/cargo-local-registry https://doc.rust-lang.org/cargo/reference/source-replacement.html

AndrewGaspar

comment created time in a month

fork hhirtz/spack

A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

https://spack.io

fork in a month

pull request commentircv3/ircv3-specifications

Add the CHATHISTORY extension specification - refactored

The pseudocode includes an example use of BETWEEN (backfilling a gap when the client lacks deduplication support The client pseudocode part needs clarification:

It seems the client is assumed to keep logs locally. This is not always

the case however: logs might be on a bouncer and fetched via

CHATHISTORY. Although no "real-life" user-facing client does that right

now because people need them to act as bouncers (irssi+ssh, weechat+its

custom protocol, kiwiirc+http, etc.), CHATHISTORY may (will?) change

this fact since it allows a client to fetch their logs dynamically from

an IRC bouncer (bouncer + user-facing client and CHATHISTORY).

The pseudocodes are indeed useful for bouncers, since they'll want to

fill the gaps in their logs.

For user-facing clients that don't keep logs, the first and third

pseudocodes don't make sense because there is no "last message relayed

to previous session": the user is presented with the latest messages

via LATEST or BEFORE, and if needed previous messages are fetched with

BEFORE. Using BETWEEN or AFTER with a "last-seen message ID/timestamp"

instead will introduce large delays when scrolling.

TL;DR: separate between the two use-cases (log filling vs infinite

scroll), and the first and third listings do the same thing.

prawnsalad

comment created time in 2 months

pull request commentircv3/ircv3-specifications

Add the CHATHISTORY extension specification - refactored

Well it still forces a client to have mutable buffers and handle the logic of receiving older messages AFTER newer messages

You need that logic for infinite scrolling anyway.

prawnsalad

comment created time in 2 months

Pull request review commentircv3/ircv3-specifications

Add the CHATHISTORY extension specification - refactored

+---+title: IRCv3 chathistory extension+layout: spec+work-in-progress: true+copyrights:+  -+    name: "Evan Magaliff"+    period: "2017"+    email: "evan@muffinmedic.net"+  -+    name: "Darren Whitlen"+    period: "2018-2019"+    email: "darren@kiwiirc.com"+---+## Notes for implementing work-in-progress version++This is a work-in-progress specification.++Software implementing this work-in-progress specification MUST NOT use the unprefixed `chathistory` or `event-playback` CAP names. Instead, implementations SHOULD use the `draft/chathistory` and `draft/event-playback` CAP names to be interoperable with other software implementing a compatible work-in-progress version. The final version of the specification will use unprefixed CAP names.++The `chathistory` batch type is already ratified and SHOULD be used unprefixed.++## Description+This document describes the format of the `chathistory` extension. This enables clients to request messages that were previously sent if they are still available on the server.++The server as mentioned in this document may refer to either an IRC server or an IRC bouncer.++## Implementation+The `chathistory` extension uses the [chathistory][batch/chathistory] batch type and introduces a client command, `chathistory`.++Full support for this extension requires support for the [`batch`][batch], [`server-time`][server-time] and [`message-tags`][message-tags] capabilities. However, limited functionality is available without support for these CAPs. Servers SHOULD NOT enforce that clients support all related capabilities before using the `chathistory` extension.++The `draft/chathistory` capability MUST be negotiated. This allows the server and client to act differently when delivering message history on connection.++An ISUPPORT token MUST be sent to the client to state the maximum number of messages a client can request in a single command, represented by an integer. `CHATHISTORY=50`. If `0`, the client SHOULD assume that there is no maximum number of messages.++The `draft/event-playback` capability MAY be negotiated. This allows the client to signal that it is capable of receiving and correctly processing lines that would normally produce a local state change (such as `JOIN` or `MODE`) in its history batches.++### `CHATHISTORY` Command+`CHATHISTORY` content can be requested by the client by sending the `CHATHISTORY` command to the server. A `batch` MUST be returned by the server. If no content exists to return, an empty batch SHOULD be returned to avoid the client waiting for a reply and to indicate that no content is available.

Thoughts on requiring the batch contents to be sorted by increasing time? This should already be done by the server (or else their chathistory impl would be very complex...).

prawnsalad

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

PR opened gdamore/tcell

Add italic code to alacritty terminfo

For tcell programs on alacritty to be able to display italics.

Source: https://github.com/alacritty/alacritty/issues/2963

+1 -0

0 comment

1 changed file

pr created time in 2 months

create barnchhhirtz/tcell

branch : alaitalic

created branch time in 2 months

fork hhirtz/tcell

Tcell is an alternate terminal package, similar in some ways to termbox, but better in others.

fork in 2 months

delete branch hhirtz/oragono

delete branch : rename

delete time in 2 months

push eventhhirtz/oragono

Hubert Hirtz

commit sha f6d5fe812fa360e97c5098a114b926ec193529e2

Update draft/rename implementation Link to the new draft PR: <https://github.com/ircv3/ircv3-specifications/pull/420> Changes in the spec: - Use standard replies instead of numerics: <https://github.com/ircv3/ircv3-specifications/pull/420/files#diff-70e90beef48dc9cf5d784d1e179ea822R44> - Allow RENAME to a different case: <https://github.com/ircv3/ircv3-specifications/pull/420/files#diff-70e90beef48dc9cf5d784d1e179ea822R42> This commit makes oragono send the PART-JOIN fallback even on case-only changes. This is so that clients don't have to worry about oragono's UTF8 casefolding. See the following comments for further info: <https://github.com/ircv3/ircv3-specifications/pull/420#issuecomment-668770837> Misc fixes: - Remove unused variable, - Add missing calls to utils.SafeErrorParam, - Don't fill replies with the user-provided "oldName", for the same reason as sending the PART-JOIN fallback.

view details

push time in 3 months

push eventhhirtz/oragono

Hubert Hirtz

commit sha 61fa36064df8ab37c9056651151e49d7686a3adf

Use the original case of the old channel name in replies

view details

push time in 3 months

pull request commentoragono/oragono

Update draft/rename impl

Still todo: use the stored channel name instead of oldName in replies (will work on that tomorrow)

hhirtz

comment created time in 3 months

push eventhhirtz/oragono

Hubert Hirtz

commit sha d37e2d204fb56333e9afccdb3965d19adca2e370

Actually always send the JOIN-PART couple So that clients don't have to worry about oragono's UTF8 casefolding.

view details

push time in 3 months

push eventhhirtz/oragono

Hubert Hirtz

commit sha 6abd9725c6162221ae5642234e442784fc703e82

Revert "Allow RENAME to a different case" Always send the JOIN-PART couple because oragono might consider channels name to be equivalent while clients would not. See <https://github.com/ircv3/ircv3-specifications/pull/420#issuecomment-668770837> This reverts commit 0103e14cf4106ae26df2afa9e4b736308dc3752c.

view details

push time in 3 months

PR opened oragono/oragono

Update draft/rename impl

New draft: https://github.com/ircv3/ircv3-specifications/pull/420 Former draft: https://github.com/ircv3/ircv3-specifications/pull/308

Quoting the new draft commit message:

Changes from the earlier PR so far:

  1. Drop MODE message from fallback requirements
  2. Switch to standard replies FAIL codes for new error cases
  3. Existing error numerics such as ERR_CHANOPRIVSNEEDED are preferred
  4. Move normative fallback mechanism to its own section and add an example
  5. Mention case changes explicitly
  6. Don't use RFC keywords in non-normative security section
  1. already done
  2. done in commit https://github.com/oragono/oragono/commit/9d86a76f655b05313583f9db7a569c1a69ebe3d5
  3. already done
  4. already done
  5. done in commit https://github.com/oragono/oragono/commit/0103e14cf4106ae26df2afa9e4b736308dc3752c
  6. N/A

Feel free to squash before merging.

+28 -21

0 comment

4 changed files

pr created time in 3 months

push eventhhirtz/oragono

Hubert Hirtz

commit sha ef704d99798576a3c4b8ef3270fbe88be0ee626c

Add missing calls to utils.SafeErrorParam

view details

push time in 3 months

create barnchhhirtz/oragono

branch : rename

created branch time in 3 months

fork hhirtz/oragono

A modern IRC server (daemon/ircd) written in Go.

https://oragono.io/

fork in 3 months

PR opened swaywm/sway

Document required '\n' in swaybar-protocol

The following statusbar output is not considered by sway to be following the swaybar-protocol:

{"version":1}[[{"full_text":"2.89","urgent":false}],

However this one is:

{"version":1}\n[[{"full_text":"2.89","urgent":false}],

Both outputs contain a header with the required values and an unfinished array of objects with the required values, but the first one is showed verbatim.

+4 -4

0 comment

1 changed file

pr created time in 3 months

create barnchhhirtz/sway

branch : typo

created branch time in 3 months

fork hhirtz/sway

i3-compatible Wayland compositor

https://swaywm.org/

fork in 3 months

issue commentircv3/ircv3-ideas

Compression

I saw it and I don't think that your friends are really representative of the average user. Please provide evidence that this is necessary.

It's alright. This idea can start from a vendored spec to provide actual feedback. Both sides showed their arguments on the question of the validity of such idea. If you don't have anything more to say on the matter, let's just skip to how this could be implemented?

To recap: compression is advertised with a capability (instead of an ISUPPORT token with a command or something, it would not allow the registration burst to be compressed). However, IIUC it is preferable to not compress the SASL negotiation, from a security POV? In this case, should compression be negotiated, it would be enabled when registration has finished (001 being the first compressed message), instead of when the capability is ACKed.

Second point: how do clients choose the compression algorithm? They can't REQ with a capability argument. I suggest the negociation to be à la SASL:

S: CAP * LS :encoding=gzip,zstd
C: CAP REQ encoding
S: CAP ACK encoding
C: ENCODE gzip
S: ENCODE gzip
... finish registration
S: *gzipped 001*

I chose "encoding" to match the "Accept-Encoding" HTTP header, but you see what I mean. The servers ACKs the compression request by simply echoing the ENCODING command.

Some people want to compress only one side of the connection (I suppose to increase security when using NickServ?). The ENCODE command could accept more parameters.

More points to be solved: should the client be allowed to request compression after it has registered? Should it be allowed to disable it at any moment?

eklitzke

comment created time in 3 months

pull request commentemersion/soju

Implement IDLE (#71)

It would be nice to add the extension spec to doc/ too. And hide the functionality behind a vendored CAP, to avoid conflicts.

-1

This is already behind an ISUPPORT flag and doesn't need a CAP (reminder that the use case for caps are to allow the server to break the original protocol, which is not the case here).

delthas

comment created time in 3 months

more