You don't then get to go and complain that the community isn't treating you well. They're right not to trust you.

You use Oracle's JS trademark as precedent, but that's woefully ignorant of how it came about. JavaScript was not a four year old open standard when Oracle came along and scooped it up. JS was a Java branding deal between Sun and Netscape.

If you want to contribute to build something good, because a strong wasm community is in your best interest, drop the attitude and don't make any more moves to sabotage the project.

If you want to lawyer up and try to exploit the fruits of the community, then do that. But you need to pick a lane. I don't see Larry hanging around HN complaining about how people are treating him on GitHub.

I don't have a dog in this fight. Prior to this thread, I didn't know about you, your company, or anyone in all these links you've posted except I remember reading a post by Lin Clark once.

I wrote another post that I deleted pretty quickly when I realized how aggressive it sounded. But it wasn't trying to be aggressive, just convey the hostility of what you did and how you should expect people to react.

As reflected in other comments in this thread, it's not in Wasmer intent to trademark WebAssembly. And we successfully course-corrected any actions way before it was even public.

We have been continuously pushing the limits of WebAssembly since we were founded. The success of Wasmer as a company solely depends on the success of WebAssembly as a technology, and is on our best interest to continue pushing it forward.

In fact, I'd argue that Wasmer has been pioneer in:

    1. Open-sourcing the first working Rust WebAssembly runtime (wasmtime existed when I created Wasmer, but was not able to run anything [1])
    2. Creating a Package Manager for WebAssembly [2]
    3. Creating WebAssembly embeddings for non-js languages (PHP, Ruby, Python, ...)
    4. Running WASI fully in a browser, including an online shell [3]

I'm totally willing to entertain arguments that the Bytecode Alliance are also acting in bad faith. It's a harsh world and open source is not all unicorns and rainbows.

But you can't just brush off the trademark issue by claiming it was unintentional. Especially when what you write here doesn't fit well with what you've written elsewhere [3]. I've gotten trademarks through lawyers before and the level of detail was an intense experience.

You seem to be claiming your lawyers independently decided to trademark WebAssembly and you signed the pages without reading them? At least that's what I can put together from your vague writing about it.

If you're not willing to give a concrete step by step post mortem of how such a clusterfuck happened, the community should (and I'm sure does) feel at liberty to not believe you in the slightest. You don't owe them an explanation, they don't owe you their trust.

You're clearly good at technology, better than me I'm sure, and I'm no slouch. You're doing impressive work and I have no wish to downplay that. But you appear to be quite bad at getting along with people. Maybe you can make your business work without developing that skill, and if that's your plan then best of luck to you. Sincerely.

[1] https://i.imgur.com/TPBH9EH.png [2] https://news.ycombinator.com/item?id=19515476 [3] https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...

Agreed, perhaps that's the best way.

> Wasmer the company might have been announced November 12 2019, but the open source project was around a year before that. I don't know what happened prior to that date to make the Bytecode Alliance members want to "veto" you as you put it, and maybe you're entirely blameless for that. As you point out, your trademark shenanigans hadn't taken place yet. But saying the "veto of Wasmer happened the same day it was announced" is misleading at best.

I think you misunderstood. I meant that Wasmer itself was vetoed from joining the Bytecode Alliance the same day that the Bytecode Alliance was announced. Wasmer was founded way before (as a company and a open-source project).

> But you appear to be quite bad at getting along with people.

It's curious this is the impression caused. I'm definitely not someone with low social skills.

EDIT: added an extra response

So the criticism in that paragraph is undeserved, I've removed it for clarity but will leave it here for posterity.

> Wasmer the company might have been announced November 12 2019, but the open source project was around a year before that. I don't know what happened prior to that date to make the Bytecode Alliance members want to "veto" you as you put it, and maybe you're entirely blameless for that. As you point out, your trademark shenanigans hadn't taken place yet. But saying the "veto of Wasmer happened the same day it was announced" is misleading at best.

As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.

Their persona bias seems to be summarized as (from the github issue):

>The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC.

Which seems a lot less like personal bias and a lot more like both you personally and your company have crossed too many lines to be considered good members of the community. Given your response was to lash out everywhere rather than take it as constructive criticism to grow with I suspect your behavior beforehand wasn't much better.

> We would need to work with a lawyer to determine the IP issues around this. It’s possible that just using the same policy as for the WebAssembly logo works, but I know that various organizations have grown more concerned about IP in this space since then.

> This is in no small part because your company, Wasmer, attempted to register “WebAssembly” and “Wasm” as trademarks. The USPTO rejected the application, but I don’t think we can assume that attempts to register a brandmark for a WASI logo would be similarly rejected.

This doesn’t seem to be a he said she said situation; gp had the chance to defend himself and all he could come up was a very weak “The trademark requests were driven by our lawyers” (and what came after that was even more shameless if you ask me): https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...

Given that context, I’d say the gp comment (especially the “personal bias” part) is likely motivated smearing.

Bottom line: don’t make up your mind just because it’s the top comment of an HN thread, or because the discrimination/racism card is played (racism card isn’t played here, it’s in the linked GH issue). If you want to form an opinion, read the other side first.

But 100% agreed, it's essential to stay critical before making your mind on a given thing.

Also, did you delete your downvoted comment then post the same thing in a new one? I saw your comment posted a while ago, in the gray, then when I refreshed before responding, bam, “0 minutes ago”. That’s not cool.

And to answer your question: yes, I deleted the comment because I thought it was going to start a non-productive discussion (it had 1 point at the moment of deletion). Then I realized deleting could provoke some other issues, and decided to repost again.

Yeah, I know there is a spectrum of people that downvote my comments... and it's ok!

Then why register?

Lawyers can't make you do anything. They can advise. They can't act without your consent.

We also course-corrected as soon as we realized of it, much before it came public a few weeks ago.

You accidentally attempted to register a trademark?

I have never heard of that. Either you are small enough that the non-trivial tediousness and cost of the process catches a lot of attention. Or you are large enough to have a general counsel overseeing a documented chain of approvals.

> the whole conversation on your end seems petty and toxic, at first glance

That's a first! Can you expand on that? Thanks!

https://github.com/WebAssembly/WASI/issues/3

The pettiness is that this looks like a non-issue blown into a flamewar where the BA has every right not to accept contributions from yourself because of past actions taken by the business you founded. I thought it was fine for them to close the issue was out of scope/focus, it didn't need more attention or for you to project your own gripes onto it.

All told this thread left a very bad taste in my mouth with respect to Wasmer, while I have a lot of respect for the BA and Wasmtime teams and I'm very glad that they found a home at Fastly.

Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not the many related problems)

Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision.

IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.

So it's not about not being a main member but rather about being basically seen as a bad actor to the community. Actions have consequences and the consequence for the trademark BS is being seen as an enemy of the community. The way to resolve that is to not annoy them about things while being as helpful as possible. Your comments on Github definitely are not that (they're adversarial, clearly annoy them with something they don't want to deal with, etc.) which simply cements their view of you being a bad actor.

edit: Your attitude is one I've seen before and it works in getting things from people who are forced to deal with you (service workers, employees, government officials, etc.). It does not work for people who can just walk away, block you or blacklist you since they will just do that.

If they are also rejecting good quality code, that's a whole other issue.

What does this mean? How does this relate to current logo? Is this a color blindness issue?

I've explained it here: https://speakerdeck.com/syrusakbary/wasi-logo-proposal

https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.h...

https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...

>Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.

Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic:

https://medium.com/@losfair/a-comparison-between-webassembly...

- RISC-V is a large family of ISAs, though Unix platform targets a much narrower definition, the RV64GC. The "Feature table" lists FP and SIMD as "in extension" but doesn't do the same for Memory layout and protection. It's seems inconceivable to me that you would use paging in a WASM-replacement context. Same for instruction length, two-byte instruction depends on the "C" extension.

- There is nothing that prevents RISC-V in the browser from denying the ability to generate code on the fly. Just like, say iOS, it could run in a "W^X" model, that is, writable memory cannot be executed from.

- atomics, again, are part of an extension, the "A" extension. They do not have to be included, and do not make sense IMO in a single-threaded WASM replacement context.

All that said, WASM is well designed. The structured control flow is a bit painful for some producers and the lack of tail recursion elimination is criminal, but running running/JITting RISC-V in the browser would almost certainly add more overhead.

> the running code is not even provided with a way to access itself.

You can do the same thing with some ELF post-processing. I have done this, and used it over several months now. It works just fine, even though there is nothing in the RISC-V standard that explicitly says this must be true.

I asked the GCC people and they consider it a bug if there's any data in the text-segment. So, at leas there is that. Maybe we can call it optional support? :)

ADD: a few of the reasons:

- When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary.

- WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.

- wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem.

- wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that.

So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!

The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.

https://github.com/fwsGonzo/rvscript

I have done that here. Example:

    APICALL(api_math_smoothstep)
    {
        auto [edge0, edge1, x] = machine.sysargs <float, float, float> ();
        x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f);
        machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x));
        return 0;
    }

Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)

https://scholar.google.com/scholar?cluster=14979605902538775...

tl;dr security introduces a lot of design constraints that RISC V doesn't have.

section 2.3 on structured control flow:

WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass.

Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons:

section 2.2:

Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory.

However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits.

https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v...

If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement.

Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.

You can send anything down the wire to the wasm env provided

1. It can instantiate wasm itself

2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)

I don't have much data around that, happy to be proven wrong. But we don't need more corporate control over package managers and code-reuse ecosystems.

Using a non-accessible logo that is hard to read provides a non-ideal experience for our visitors, so we can't really use it unless it becomes more polished.

This forced wapm to use a different WASI logo than the "official" one, which is also a non-ideal experience (it adds fragmentation). That's why we believe is just better to push all along a bit more polished logo.

Is such a simple thing to fix, that I'm surprised of the amount of flamewar that it generated.

[1] https://wapm.io/interface/wasi