Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: WAPM – WebAssembly Package Manager (wapm.io)
186 points by syrusakbary on March 2, 2022 | hide | past | favorite | 47 comments
Hi HN!

I’m Syrus, from the Wasmer team. We just released the new version of WAPM that is an order of magnitude better than the previous one (that we also announced here in HN two years ago! [0]), enabling an incredible experience for using and publishing WebAssembly packages.

The tech stack that we are using includes:

* Python and Django (for the backend) with Graphene (for the open GraphQL API [1]) and Django Channels with websockets over GraphQL [2] for subscriptions

* Next.js [3] with React-Relay [4] and Tailwind.css [5] for the frontend

* WebAssembly and Wasmer [6] (for the online shell)

Vercel for serving the frontend and GCP for serving the backend.

Please let me know if you have any questions, I’d be very happy to answer them!




This is basically a package repo of WASM file(s), which seem to have been compiled from Rust source mostly, but other language that can be compiled to WASM would work too.

And from what I've read the CLI downloads the WASM and runs it. The "runs it" part is interesting, as it's cross platform - so does it run a JS engine, e.g like V8 or NodeJS?

I don't personally like the idea, esp since Rust can compile to all those supported platforms anyway, and the native code would be so much faster.

It says on the website that it is opensource, since 2019, but the Github account has zero repos.

The website looks flash, but has many spelling errors and typos, and so if little things like this get through after 3 years of development, then the chances of malicious code getting through is very high.


Wasmer Inc (they run wapm.io) basically wants to own the Wasm ecosystem the way that NPM has owned the JavaScript world. This isn't run by an org like Apache, or CNCF. They are VC backed and and have had some internal shakeups, a story about this was posted to HN awhile ago.

The site doesn't inspire a lot of confidence, even the about page results in a 500 error. https://wapm.io/about

As does support, https://wapm.io/support

The future needs a better solution to this problem than a single company owning the package repo.


> Wasmer..wants to own the Wasm ecosystem

They tried to trademark the terms WASM and WebAssembly.

https://uspto.report/company/Wasmer-Inc

https://news.ycombinator.com/item?id=24900186


Isn’t the big difference between running some random rust from the internet, and a WASM file, the sandbox in which WASM runs. This has some security advantages. And as you also point out, it’s like an abstraction over various languages which also can generate WASM (Go, Swift, C#, etc).


It looks like this is focused on primarily on executables, but there is a mention of libraries.

I was looking into WASM libraries recently, specifically WebAssembly Interface Types (WIT), and my conclusion is that WASM libraries are experimental and poorly supported right now (unless you only have i32/i64/f32/f64 as parameters and returns).

I couldn't find any elaboration in the documentation on libraries, what level of supported does this have? Is interface type implemented?


Looks cool! A question--your tag line says:

"Apps, libraries, and native executables that run on Linux, macOS, and even Windows."

The 'even Windows' makes me wonder whether Windows support is fragile or not fully baked? I don't know a lot about WASM--does it generally not work well on Windows? If it's working smoothly, I'd consider taking that 'even' out.


Just trying to run some things on windows and it does look like maybe it's not fully formed. quickjs panicked with 'not implemented: VirtualFile::poll is not implemented for non-Unix-like targets yet'. Just before that irb didn't work with just a generic crash.

I do love the initiative though.


We have a PR that addresses the poll issue in both Windows and JS environments, but it's not yet merged (although that's what the WAPM online shell uses!) :)


Fixed! Thanks for the feedback!


Looks very interesting, though the Javascript demo doesn't seem to work (Firefox 97.0). The following error gets logged into my console:

> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://registry-cdn.wapm.io/packages/_/sqlite/sqlite-0.2.2.....

Looks like you'll need to add a `Access-Control-Allow-Origin` header to your repository to get it to work right.


I just dug a bit into the issue.

It seems Firefox is not treating the COOP/COEP headers as it should, and it's interpreting `Cross-Origin-Opener-Policy: same-origin` as to only allow the same domain (wapm.io) but not any parent subdomain (registry-cdn.wapm.io), while Chrome supports fully this use case treating both domains as `same-origin`.

In summary, I believe it's a bug in Firefox that I'm not sure how can be bypassed.

EDIT: I got things wrong. The issue is now fixed in Firefox


Reading the spec[1] this behaviour might actually be spec compliant (as the algorithm described matches on hosts rather than on domains, unless the provided header value is same-origin-domain) but I don't think that's what you'd actually want the headers to do. This might also be a spec bug?

Thisnis the first time I'm reading about this header, but if you know more you should file a bug with Firefox to get it confirmed and/or fixed.

Security headers like these are hard to keep up with, there's bound to be a bug in the implementation somewhere. At least it fails safely this time!

[1]: https://html.spec.whatwg.org/multipage/origin.html#the-coop-...


I got things completely wrong. The issue was that the wapm.wasm program was doing an HTTP request with a custom "User-Agent", and Firefox was blocking it because of that but showing the wrong message in the console.

Good news is... right now things work as they should in Firefox!


"Run it in the browser" is pretty cool! I've played some with Rust / WASM in the past, but at the moment don't have bandwidth at the moment to try WAPM/Wasmer.

Assuming the goal is able to use software written in any language as easy as it is if you were a java or dotnet developer, how do you plan on getting this as big as npm or PyPI? A lot of the examples I've clicked on seem to be forks of the projects instead of pulling in the original source as a git submodule.

My Bazel-based bias would be to assume WASM is mostly an execution platform target, just like linux/x86_64 or macOS/m1, and I should be able to pull in and compile the source myself at any version I choose. It is hard enough as it is to pull in official third-party library sources into Bazel due to the varied ways libraries are built, so I don't see how the current official maintainers of projects will also volunteer to also maintain their build process and profile for WAPM too.

Some feedback about potential issues:

When I search packages for "Library" for "All Time" nothing shows up in the list. But things like sqlite and ken-matsui/jyt are labeled as "Library" on the detail page, while their docs make them look like "Standalone".

Package details probably should be sanitized. For example in rajsite/exorbitant the GITHUB attribute uses a git+https URL which isn't helpful for a web browsing session. And the HOMEPAGE says https://github.com/rajsite/exorbitant, but the actual link goes to "cowsay.overnice.com". I haven't created an account to see how a package is created, but a GitHub project link should only accept user/repo to generate the URL automatically.

The collaborators list of ken-matsui/jyt is empty, yet the package says it was last updated 2 days ago. The tooltip on the avatar icon says "ken-matsui", but it isn't an alternative way to click to the profile/namespace page. Also last updated-by should display the user/namespace name of who updated it, even though it is implied.

Recommend cleaning out or suppressing in search package that haven't been updated or attested to be up-to-date within a few months. For example "sqlite/sqlite" is showing up for me in "Popular Standalone Apps" on the homepage, but it hasn't been updated in 2 years. I see that you own the package, but also understand that you need to get the repository seeded with useful packages, and that a startup can take many years before hitting the next point in the change of the growth curve.


Thanks for the info and the work done.

I don't quite understand how this fits in the picture of other package managers. If it's capable of being a multi-platform package manager, that would be great, but I suppose it's a complex task to have software and libraries running on all operating systems without any difference in usage.

Is it a stated goal of this tool? Am I looking at this the wrong way?


I'm a big fan of WebAssembly and the idea of WAPM! It's very cool, and I'm hopeful for a more interoperable future.

A quick bug report: the "Open in Shell" feature seems to fail in Firefox due to a CORS problem? It did work in Chrome when I tried it though.

Another question - it seems like a lot of the packages are pretty out of date, for instance the end-of-life Python 3.6 - clicking through to the GitHub page it looks like it's managed by a wapm-packages organization, and managed by Wasmer itself. Will they get more updates now that the new version of WAPM is out? Is it more of a community driven thing? (And an additional bug report, the Wasix link in the wapm-packages/python README is broken)


I was able to get the shell running in Firefox (for example, running ls or echo "hello"), but I think you are right that something is off when you try to install a package. Looking into it right now!

Some packages (like Python 3.6) are a bit out of date. We are planning to update most of them as languages add native support for Wasm and WASI. But yes, in general the packages are mainly community driven.

For example, you should be able to try irb / Ruby latest version here (thanks to their WASI support upstream a few weeks ago!)

https://wapm.io/katei/irb


irb in firefox gives me:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://registry-cdn.wapm.io/packages/katei/irb/irb-0.1.3.ta.... (Reason: CORS request did not succeed). Status code: (null).

It is every package. Looks neat anyway! thanks.


The issue should now be fixed in Firefox! :)


Wait, I thought originally it was a NPM for WebAssembly.

But it looks like a WebAssembly version of Homebrew.


It's kind of both at the same time :)


It seems WebAssembly itself defines text and binary formats for modules, but I'm wondering what this particular package format looks like. A directory of files? What are they? How does linking work?


I found this yesterday and, maybe it’s because I’m viewing on mobile, but the Explore functionality is very confusing. For instance sorting alphabetically… doesn’t. Search shows potential matches in the autosuggest that don’t show up in actual search results. Filters clear search queries and vice versa. Yesterday I didn’t see a “load more” button, I’m pleased to see that today because currently it seems like the only way to actually explore.


What forms of input/output are supported in WAPM packages? Obviously stdout and stdin, but are some sort of socket API supported?


Wasmer will soon support sockets, which will allow running networking in packages server-side.

On the client-side of things, browsers don't currently support arbitrary socket connections it so that might be a bit tricky! But still feasible, for example you can proxy the socket packets through websockets and a main server that handles the outside connections


Does client-side Wasmer support WebRTC Data Channels?


With NPM I can install packages, develop with them, and then use webpack to bundle everything into a single JS file. How can I bundle the WAPM packages I install into a single WASM file?

Also is there a way to use the WAPM packages I install from emscripten? How would I import these packages from C?



How far are we from the day when most software on the average desktop or mobile is wasm?


> * Python and Django (for the backend) with Graphene (for the open GraphQL API [1]) and Django Channels with websockets over GraphQL [2] for subscriptions

Why doesn't the backend use WASM and/or Wasmer?


Great question. The main reason is time to market (similar on why Deno used Node.js at the beginning for their website)

I also was way faster to develop it in Python with a framework I was familiar with rather than in other language that compiles to Wasm!

But everything is made so in the future it could be executed with Wasmer :)


In your view how does the chosen technology stack impact these three measurements:

* user experience

* speed of feature development

* operational cost including cloud billing and staffing/training costs


I was surprised that I couldn't read the source for it. Doesn't appear to be open source.


is the the tech stack for wapm.io backend open source?, I've been looking around for a decent cataloging / registry tool. afaicr the only oss extant one is ansible's galaxy.


yes please-- had debated building this -- trad utils so can do more client-side processing -- imagemagick, ffmpeg, come to mind -- think some may have FOSS ports


Wasn't there some Wasmer controversy with the CEO or founder or something last year? Not trying to disparage the company or their work, I was just reminded of it by this post.


Wasmer is considered a bad actor by many, and there are many in the WASM space who want nothing to do with them. It's no accident Wasmer isn't a part of the Bytecode Alliance [1].

A particularly damning incident was the time they tried and failed to trademark "WEBASSEMBLY", an open W3C standard [2] [3]. There are many choice words for companies trying these kinds of stunts.

Webassembly is growing despite Wasmer's existence. Not because of them. Be cautious.

[1]: https://bytecodealliance.org/

[2]: https://tsdr.uspto.gov/documentviewer?caseId=sn88703780&docI...

[3]: https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...


Thanks for showcasing your concerns regarding the trademarks. We created a public response to make sure those concerns are addressed. Hope this sheds some light:

https://wasmer.io/posts/wasmer-and-trademarks



Sounds toxic, which is sort of my experience with WASM as a whole. Browser vendors should already be ashamed for what they've done but now they are ready to try to convert all your apps into spyware garbage.


In this day and age, it's arguably irresponsible to publish any tooling that does not organically integrate a requirement to use Sigstore for all packages allowed to be uploaded.

The very first things you should be talking about on your service is provenance mechanisms and security.

I don't believe I saw anything related to thos topics on your site. Did I miss it?


WAPM already has a mechanism for signed packages (although not through Sigstore, first time I'm hearing of it but thanks for the reference!)

You can read more about it here: https://medium.com/wasmer/securing-wapm-packages-with-packag...


IMO just signing packages is a weak form of trust. Even without potentially using Sigstore, does WAPM now let you lock based both on the versions of dependencies, as well as the hash of their contents? I didn't see any mention of lock files with hashes anywhere.


In fairness, Sigstore is a pretty new technology. Existing package managers haven't integrated it yet, though are working towards it. For example, I've been working with colleagues on proposing a design for RubyGems[0]. And as far as I know we're about as far ahead as anyone has gotten.

There's an informal group of software repo folks meeting with some assistance from the OpenSSF. WAPM folks, please feel free to hit me up at my work email (in profile).

[0] https://github.com/rubygems/rfcs/pull/37


Sure, but "existing package managers haven't integrated it yet" because of a burden of legacy and wanting to ensure a smooth transition for the ecosystem; not because it's hard to integrate. It should be extremely simple for a greenfield package-ecosystem, that isn't replacing any other mechanism with Sigstore, to adopt it.


From what I've seen in a few minutes looking at Sigstore, it seems they require packages to be stored in a OCI-compliant store... which it differs on how package managers are storing packages. So it might be not as trivial.

Or perhaps I'm missing something?

https://github.com/sigstore/cosign


It's an understandable confusion. The key components are Fulcio, a certificate authority, and Rekor, a transparency log. Fulcio generates short-lived public certificates for (approximately) each signature. Rekor stores the certificate and signature.

In the case of cosign, this is done for container images and the signature is then made available via the OCI registry API. But it needn't be; for RubyGems we envisage storing log extracts side-by-side with .gem files. We anticipate other package systems will do similarly. One of our discussions has been whether we can converge on a shared format for those extracts.

This section of the RubyGems signing RFC might help: https://github.com/Shopify/rfcs/blob/new-signing-mechanism/t...




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: