hi #digitalSovereignty and #privacy folks!

are there any #Canadian organizations that work in the online privacy, #interop, and/or digital sovereignty spaces?

basically like the EFF, but Canadian; the Chaos Computer Club, but Canadian; you get the idea.

The CCLA seems to be doing some work on this (https://ccla.org/our-work/privacy/), but I am looking for more targeted/focused orgs.

There's also https://openprivacy.ca/work/, which I had not heard of.

Boosts OK & encouraged! Thank you!

#Canada #boost4reach

hi #digitalSovereignty and #privacy folks!

are there any #Canadian organizations that work in the online privacy, #interop, and/or digital sovereignty spaces?

basically like the EFF, but Canadian; the Chaos Computer Club, but Canadian; you get the idea.

The CCLA seems to be doing some work on this (https://ccla.org/our-work/privacy/), but I am looking for more targeted/focused orgs.

There's also https://openprivacy.ca/work/, which I had not heard of.

Boosts OK & encouraged! Thank you!

#Canada #boost4reach

hi #digitalSovereignty and #privacy folks!

are there any #Canadian organizations that work in the online privacy, #interop, and/or digital sovereignty spaces?

basically like the EFF, but Canadian; the Chaos Computer Club, but Canadian; you get the idea.

The CCLA seems to be doing some work on this (https://ccla.org/our-work/privacy/), but I am looking for more targeted/focused orgs.

There's also https://openprivacy.ca/work/, which I had not heard of.

Boosts OK & encouraged! Thank you!

#Canada #boost4reach

@steffen @feb

/
@crossgolf_rebel @fasnix @wuffel
Was ist mit Euch?

Es kann ganz allgemein im w3 "Big Blue Button" starten [Nutzende, Entwickelnde, Fördernde egal] und bei Interesse könnten wir dann taskforces bilden.
#fediverse #activitypub #interop #c2s
Würde dann 1 Aufruf starten …
policy wie immer, be excellent, no nazis und so :)

Another great new CSS feature that is starting to be available in more browsers is field-sizing, which allows you to size an input to fit its value with:

field-sizing: content;

Great for UI like tags, where you want to be able to type directly into them and have them automatically resize to fit the text.

( #CanIUse shows the feature as not being available in Safari Technology Preview, even though all the individual child features show that it is available)

#Interop #WebCompat #CSS

Another great new CSS feature that is starting to be available in more browsers is field-sizing, which allows you to size an input to fit its value with:

field-sizing: content;

Great for UI like tags, where you want to be able to type directly into them and have them automatically resize to fit the text.

( #CanIUse shows the feature as not being available in Safari Technology Preview, even though all the individual child features show that it is available)

#Interop #WebCompat #CSS

Zig / C++ Interop

https://tuple.app/blog/zig-cpp-interop

#HackerNews #Zig #C++ #Interop #Programming #Languages #Developer #Tools #Tech #News

If you haven’t used it before, image-set() is used in CSS in any place where you’d normally use an image. Here’s a simple example where the browser will use JPEG XL if it supports it, or JPEG if it doesn’t:

background-image: image-set(
url("bg.jxl") type("image/jxl"),
url("bg.jpg") type("image/jpeg")
);

( you can also specify resolutions, e.g. url() 2x type() )

#Interop #WebCompat #JPEGXL

It’s really nice that we now have wide support for image-set() in browsers so that it’s possible to use JPEG XL in browsers that support it (with automatic fallback to other formats for browsers that don’t), even for cases like background images, which used to be a pain point when all we had was <picture>.

This is an example of the kinds of big wins that can be achieved through the #Interop Project.

#WebCompat #JPEGXL

The XMPP Interop Testing framework helps developers check their XMPP software for compatibility across servers and clients.

In our latest update, we additional support for more freedom-respecting, open source CI systems 🙌

Newly added: Forgejo, Jenkins, Drone, Harness and Woodpecker

Already supported: GitHub, GitLab, CircleCI, Bamboo & more - now 11+ CI options in total!

Test all the things!

https://xmpp-interop-testing.github.io/2025/09/14/lots-more-options.html

#XMPP#Interop#CI#OpenSource

The XMPP Interop Testing framework helps developers check their XMPP software for compatibility across servers and clients.

In our latest update, we additional support for more freedom-respecting, open source CI systems 🙌

Newly added: Forgejo, Jenkins, Drone, Harness and Woodpecker

Already supported: GitHub, GitLab, CircleCI, Bamboo & more - now 11+ CI options in total!

Test all the things!

https://xmpp-interop-testing.github.io/2025/09/14/lots-more-options.html

#XMPP#Interop#CI#OpenSource

The XMPP Interop Testing framework helps developers check their XMPP software for compatibility across servers and clients.

In our latest update, we additional support for more freedom-respecting, open source CI systems 🙌

Newly added: Forgejo, Jenkins, Drone, Harness and Woodpecker

Already supported: GitHub, GitLab, CircleCI, Bamboo & more - now 11+ CI options in total!

Test all the things!

https://xmpp-interop-testing.github.io/2025/09/14/lots-more-options.html

#XMPP#Interop#CI#OpenSource

Yesterday I released new versions of https://thi.ng/wasm-api (and its add-on packages), a modular and extensible bridge API & toolchain for hybrid JS/TS/Zig/WebAssembly apps, now updated to be compatible with the latest Zig version 0.15.1...

The update addresses some of Zig's breaking syntax & build system changes only, nothing on the JS/TS side has changed. As a result https://thi.ng/wasm-api-dom has a slightly revised internal structure (also a breaking change, but nothing major & unavoidable). All bundled Zig examples[1] in the repo have been updated too, take a look for reference (if needed).

FYI More details about the Zig language changes here:
https://ziglang.org/download/0.15.1/release-notes.html#Language-Changes

Specifically, the removal of usingnamespace has had a major impact on the existing handling of generated types in these wasm-api support packages (or your own) and now forces an additional level of hierarchy in terms of namespacing. This is because usingnamespace enabled a form of namespace merging, which allowed the generated WASM⭤TS interop types (written to their own sourcefile) to be merged/hoisted into the main library module.

For example, previously after importing const dom = @import("wasm-api-dom"); we could refer to a type via dom.WindowInfo. Now with namespace merging removed, we have to use dom.types.WindowInfo. As I said, it's not a major departure, but a breaking change nonetheless[2]...

The build.zig file bundled with https://thi.ng/wasm-api is now also only compatible with Zig 0.15.1 (for now). Build files for older Zig versions are still included too (in the same directory)[3].

Lastly, once more for the record: The wasm-api bridge itself is NOT tied to Zig (or a particular version), however it's the main use case/language for my own WebAssembly use cases...

[1] https://github.com/thi-ng/umbrella/tree/develop/examples (all examples starting with zig-*)

[2] The existing design of these modules helped to keep these breaking changes to a minimum in userland code and these updates are all following the same uniform pattern (i.e. exposing interop types via modulename.types.TypeName...)

[3] https://github.com/thi-ng/umbrella/tree/develop/packages/wasm-api#using-the-zig-build-system

#ThingUmbrella#Zig#Ziglang#WebAssembly#WASM#TypeScript#JavaScript#Interop

Yesterday I released new versions of https://thi.ng/wasm-api (and its add-on packages), a modular and extensible bridge API & toolchain for hybrid JS/TS/Zig/WebAssembly apps, now updated to be compatible with the latest Zig version 0.15.1...

The update addresses some of Zig's breaking syntax & build system changes only, nothing on the JS/TS side has changed. As a result https://thi.ng/wasm-api-dom has a slightly revised internal structure (also a breaking change, but nothing major & unavoidable). All bundled Zig examples[1] in the repo have been updated too, take a look for reference (if needed).

FYI More details about the Zig language changes here:
https://ziglang.org/download/0.15.1/release-notes.html#Language-Changes

Specifically, the removal of usingnamespace has had a major impact on the existing handling of generated types in these wasm-api support packages (or your own) and now forces an additional level of hierarchy in terms of namespacing. This is because usingnamespace enabled a form of namespace merging, which allowed the generated WASM⭤TS interop types (written to their own sourcefile) to be merged/hoisted into the main library module.

For example, previously after importing const dom = @import("wasm-api-dom"); we could refer to a type via dom.WindowInfo. Now with namespace merging removed, we have to use dom.types.WindowInfo. As I said, it's not a major departure, but a breaking change nonetheless[2]...

The build.zig file bundled with https://thi.ng/wasm-api is now also only compatible with Zig 0.15.1 (for now). Build files for older Zig versions are still included too (in the same directory)[3].

Lastly, once more for the record: The wasm-api bridge itself is NOT tied to Zig (or a particular version), however it's the main use case/language for my own WebAssembly use cases...

[1] https://github.com/thi-ng/umbrella/tree/develop/examples (all examples starting with zig-*)

[2] The existing design of these modules helped to keep these breaking changes to a minimum in userland code and these updates are all following the same uniform pattern (i.e. exposing interop types via modulename.types.TypeName...)

[3] https://github.com/thi-ng/umbrella/tree/develop/packages/wasm-api#using-the-zig-build-system

#ThingUmbrella#Zig#Ziglang#WebAssembly#WASM#TypeScript#JavaScript#Interop