Should we rename Fleet SDK to something with ergo in its name?

[capt-nemo429]

In short, I think Fleet is a great name, but it does not reflect the specific purpose of our Ergo SDK. Should we rename it?

Fleet is a catchy name that fits well in the Nautilus narrative, but it may cause confusion for newcomers. We often see them choosing outdated and unsafe libraries like ergo-ts and ergo-js over actively maintained ones like AppKit, sigma-rust, or Fleet.

I believe this is partly due to the naming. The tooling name should clearly indicate its purpose and scope. Therefore, I would like to hear your opinion on renaming Fleet to something that includes Ergo/ERG in its name.

Some possible alternatives are:

• ErgoKit
• erg.ts
• w3erg (web3 + erg)
• ErgoSDK.js
• something else?
• keep it as Fleet, you damn perfectionist.

v1.0 is quite close and that will represent breaking changes for implementors, so if we are going to rename it, a major release is a good opportunity for it.

I would love to know your opinions and suggestions on this proposal.

[NoahErgo]

Fleet is such a cool name, maybe something like Fleet JS SDK?

[mgpai22]

w3erg.js would be nice

[nn-dmt]

i like fleet but if you're going to change it to something incorporate dapp

dappSDK.js

[capt-nemo429]

Fleet is such a cool name, maybe something like Fleet JS SDK?

i like fleet but if you're going to change it to something incorporate dapp

dappSDK.js

If we are going to rename it, batter to have erg/ergo in its name.

w3erg.js would be nice

I like this one too.

[ross-weir]

Agreed

IMO something like ergo-web3 would be good. Having "blockchain" and "web3" in the name is a fairly common convention:

• https://www.npmjs.com/package/@solana/web3.js
• https://www.npmjs.com/package/@alephium/web3
• https://www.npmjs.com/package/web3-eth
• etc

Not a fan of abbreviating to "w3", IMO it's too close to "w3c" which is also sometimes just called w3

[ldgaetano]

If fleet gets renamed then so should appkit. If appkit name does not change then what about appkit-js? If appkit changes then maybe something like ergosdk and ergosdk-js.

[aslesarenko]

First of all, I don't think the name is such a big problem. The greater problem is existence of ergo-js and ergo-ts. They should redirect to Fleet ideally.

Appkit actually already called ergo-appkit for exactly the reasons described in this issue. It has ergo and purpose in the name.

So, if do renaming, I suggest ergo-appkit-js for repo, and Appkit.js for discussions.
This will be consistent with Sigma, Sigma.js naming.

From design perspective, Appkit is dApp facing Java/Kotlin library on top of Sigma.
Similarly if Fleet is renamed to Appkit.js then it will support its role of dApp facing JS/TS library on top of Sigma.js

Other issues:

• While ergo-js is archived, there is no clear banner that it shouldn't be used.
• ergo-ts should be archived with a BIG banner on the repo, but it belongs to coinbarn.

[glasgowm148]

Reiterating my comments from the chat below and adding some further discussion

Would be good to have them all using the same naming if that’s logical. Something like

• ErgoKit JVM
• ErgoKit Rust
• ErgoKit JS

That would be the ideal, but unpractical at this point as there are many teams involved. - nemo

Yeah appreciate the difficulties in orchestrating a wider change, but it might be our best shot at doing so before the ecosystem matures any further.

Certainly FleetSharp would need to rename in either case. But would be ideal if we could either change sigma-rust and Appkit too, or alternatively, rename Fleet to match one of them to make it a bit more cohesive.

Another problem is that this naming structure presumes the same, or at least closer APIs. - nemo

I would've assumed they have a similar level of functionality personally but don't have a good grasp on the significance of this. But isn't that something we should be aiming for anyway?

• The combination of Fleet and Sigma.JS will provide a similar level of functionality to Appkit, right? So what about JS-AppKit or Appkit-JS ?
• sigma-rust is kinda like a basic version of AppKit using a port of the interpreter in rust + tx building tools and bindings, I did see @zackbalbin was working on a rustkit last year, so does it make sense to develop this as Appkit-Rust and use it as the entry point?

@aslesarenko @pulsarz @greenhat

[aslesarenko]

@glasgowm148 @capt-nemo429
Appkit was designed as a next abstraction layer on top of Sigma. This gives a lot of freedom on the core level in Sigma, while keeping dApp facing APIs stable. (see my above comment)
With the availability of Sigma.js, Fleet (or should I call it Appkit.js) can play the same role for JS/TS.

Sigma-rust, as the name suggests, is a port of Sigma, not Appkit. Thus it is on the core level and is wrapped in JS library (like Fleet)
Appkit-rust makes sense if there is a need to have idiomatic Rust interfaces for transaction building similar to Appkit's and Fleet's builders. While it is possible to do, I'm not sure we need Appkit-rust library at the moment. Much more important for sigma-rust to be on par with Sigma v5.0 now and v6.0 in the future.
Also, upcoming Multisig support in Sigma will be available in both JVM and JS, so another work for sigma-rust to catch up.

[pulsarz]

Reiterating my comments from the chat below and adding some further discussion

Would be good to have them all using the same naming if that’s logical. Something like

• ErgoKit JVM
• ErgoKit Rust
• ErgoKit JS

That would be the ideal, but unpractical at this point as there are many teams involved. - nemo

Yeah appreciate the difficulties in orchestrating a wider change, but it might be our best shot at doing so before the ecosystem matures any further.

Certainly FleetSharp would need to rename in either case. But would be ideal if we could either change sigma-rust and Appkit too, or alternatively, rename Fleet to match one of them to make it a bit more cohesive.

Another problem is that this naming structure presumes the same, or at least closer APIs. - nemo

I would've assumed they have a similar level of functionality personally but don't have a good grasp on the significance of this. But isn't that something we should be aiming for anyway?

• The combination of Fleet and Sigma.JS will provide a similar level of functionality to Appkit, right? So what about JS-AppKit or Appkit-JS ?
• sigma-rust is kinda like a basic version of AppKit using a port of the interpreter in rust + tx building tools and bindings, I did see @zackbalbin was working on a rustkit last year, so does it make sense to develop this as Appkit-Rust and use it as the entry point?

@aslesarenko @pulsarz @greenhat

Certainly willing to change the FleetSharp name. I agree we might do good with some better names.

[c8e4]

Please do not rename.

When learning a new technology and searching for libraries the cognitive context load is already pretty high. Personally i found it very confusing and overwhelming at the start of my journey that almost anything had either sigma or ergo in it's name. When everything has the same prefix, the prefix becomes meaningless. I hope other developers will follow fleet's example.
Publishing few ultra simple example of fleet usage on medium, twitter or similar should be enough to guide majority of the people to the right library.

[ross-weir]

I agree with nemos original sentiment but also not sure if it's worth prioritising. Cool to see so many people care about package naming 🤗

For me it comes down to what we want fleet to be, an AppKit/Sigma.js library vs a JavaScript library for Ergo.

Edit: Talked to nemo, it appears the intent behind using Sigma.JS is mostly in testing envs not frontend dapps which means the bundle size matters way less, but keeping this here anyway:

In regards to fleet being a Sigma.js library - have we ensured this is a valid path to take? I ask this because the sigmastate-js JavaScript package is currently 11MB in size making it unusable for browser based JS which is most dapps. For comparison I made a issue in sigma-rust that a bundle size over 3MB was out of hand and we need to address it, sigmastate is over 3x this size. IMO If we want to go this route we need to stop now and ensure we can get the bundle size to something that is practically usable. This is also ignoring the fact I think Scala.JS is going to be a hard sell to JS devs 😄

I personally feel fleet could be something more than a JavaScript appkit, there's other popular library functionality that it could provide that aren't relevant outside the browser like react hooks/wallet connector/etc. Following web3 naming conventions would be great for this. "Appkit" makes the library familiar to people already in Ergo whereas web3 naming makes it discoverable by devs from other ecosystems

[capt-nemo429]

I'm glad to see you guys care about Fleet SDK and really appreciate your feed back.

@ross-weir:
IMO something like ergo-web3 would be good. Having "blockchain" and "web3" in the name is a fairly common convention

I like how ergo-web3 sounds.

@lucagdangelo:
If fleet gets renamed then so should appkit. If appkit name does not change then what about appkit-js? If appkit changes then maybe something like ergosdk and ergosdk-js.

Good point!

@aslesarenko:
First of all, I don't think the name is such a big problem. The greater problem is existence of ergo-js and ergo-ts. They should redirect to Fleet ideally.

Yeah, that makes me think. Indeed, the real problem is the existence of outdated/unsecure libraries not the name. Unfortunately we can't do much about that.

@c8e4:
When learning a new technology and searching for libraries the cognitive context load is already pretty high. Personally i found it very confusing and overwhelming at the start of my journey that almost anything had either sigma or ergo in it's name. When everything has the same prefix, the prefix becomes meaningless. I hope other developers will follow fleet's example.

Excellent point, I agree that prefixes become meaningless if everything is ergo or sigma prefixed, but we have something very important here, all of them refers to ergo somehow thus creating a clear semantic connection. If I'm a newcomer and I see a lib called Fleet, the first thing that will come to my ming is that is some kind of fleet management library and probably not worths exploring, generating even more confusion, but if I find something called ergo-ts, my first impression will be different. See my point?

Publishing few ultra simple example of fleet usage on medium, twitter or similar should be enough to guide majority of the people to the right library.

Definitively something that worths exploring, make the framework popular and don't worry about naming 🤔.

---

Personally, I'm between @ross-weir's and @c8e4's suggestions. But always open to discussions.

[capt-nemo429]

@aslesarenko:
Appkit was designed as a next abstraction layer on top of Sigma. This gives a lot of freedom on the core level in Sigma, while keeping dApp facing APIs stable. (see my above comment)
With the availability of Sigma.js, Fleet (or should I call it Appkit.js) can play the same role for JS/TS.

I believe Sigma.JS must be used where it shines: compiler, wallet, interpreter, and so on, on the back-end side. Furthermore, bundle size can be improved a lot once it's stable, from ~11mb to ~2mb, it's far from ideal for front-end usage but can be usable for some edge cases if necessary.

Bundle size is a big concern to Front-end devs and it IS a real concern IMO. Having to load megabytes of code to do something simple as building a transaction or parsing a constant, is a no-go for most of them.

Package Structure

• Front-end packages - tiny hand-crafted packages. All are under 40kb and tree-shakeable which can reduce the bundle size even more by eliminating dead code.

  • core - transaction building and base models.
  • crypto - hash functions and byte encoders.
  • common - utility functions shared across Fleet and Sigma.JS packages.
  • serializer - basic Sigma constant serializer and parser. Currently full primitive and generic types support.

• Back-end packages, bundle size is not a big problem for backend and unit testing usage, so the following packages will be mostly wrappers around Sigma.JS.

  • compiler - ErgoScript compiler.
  • mock-chain - A simulated blockchain environment that can be used in composition with the compiler package to unit test contracts.
  • wallet - Key management and transaction reduction and signing.

Naturally, there are some edge cases, if one needs to parse a box that contains an ErgoTree v0 or work with AVL Trees, for example, Fleet's serializer will not be able to handle that, luckily we have Sigma.JS and sigma-rust to the rescue.

[ross-weir]

@capt-nemo429

Personally, I'm between @ross-weir's and @c8e4's suggestions. But always open to discussions.

Maybe a third option: keep the name as it is but make like a @fleet-sdk/ergo-web3 package that acts as a prelude package/single entrypoint and exposes all commonly used/needed functionality from other fleet packages

[mgpai22]

Honestly, I don't think the name is of much issue.

A priority should be getting more documentation!

[gipo355]

Honestly, I don't think the name is of much issue.

A priority should be getting more documentation!

Agree with this. A new dev probably googles ergo crypto JavaScript/typescript library/SDK/development

It's possible more documentation under a domain (docusaurus maybe?) solves both problems as SEO will work for this.

[aslesarenko]

@capt-nemo429 @ross-weir
The 11Mb is unoptimised size, the optimised full package is 2.1MB, however large part of it is compiler.
Here is the possible plan for Sigma modularisation (this new modules can be independently published artefacts for both JVM and JS).

ergoplatform/sigmastate-interpreter#902

[aslesarenko]

@ross-weir @capt-nemo429
I don't agree with putting so much emphasis on the bundle size.
Without compiler Sigma.js is only 1.4M, it is nothing for 80% of cases with current networks and CDNs.
For applications, It makes sense to optimise productivity and time to market, not performance.
A new feature with some inefficiencies is infinitely more valuable that no-features without inefficiencies.

Example, ErgoNode has tons of potential optimisations still, even though many has been done, but, most of the done optimisations was observable bottlenecks first, and only then they was optimised away.
This is the only viable strategy with our small team.

Another example, MrStahlfelge had ZERO issues with crypto, serialisers, signing, interpretation, TX building etc, because he reused Sigma code entirely.
And he cross-compiled it to both Android (yes it is cross-compilation to different VM) and also cross-compiled to RoboVM (it is yet another cross-compilation).
This cross-compilation was one time job (2 weeks for each new VM) and then he spent time on actual new code and features.

Could we have lower app size?
Yes we could do some optimisations, but this has never been an issue. There was once latency issue with first tx singing due cold code in the VM. This was solved by speculatively running in background a fake tx signing just to warm up the JIT in VM, and that solved the glitch problem.

I'm sure similar solution can solve any latency problems in the frontend due to a large library size, just warm up the code in advance.

[greenhat]

Reiterating my comments from the chat below and adding some further discussion

Would be good to have them all using the same naming if that’s logical. Something like

• ErgoKit JVM
• ErgoKit Rust
• ErgoKit JS

I like the idea of a unified name for SDKs, but OTOH, what name should sigma-rust JS bindings have? "ErgoKit Rust JS" looks weird.

[capt-nemo429]

It looks like the name is not that big of an issue, I would like to say thank you for the insights and amazing discussions. :)

Let's keep it as Fleet and work on better documentation/branding.

[gipo355]

thrown a hint earlier but could give a look at (https://docusaurus.io/showcase) for quick scaffolding maybe? @capt-nemo429

(https://www.npmjs.com/package/docusaurus-plugin-typedoc)

(https://github.com/tgreyuk/typedoc-plugin-markdown)

(https://docusaurus.io/feature-requests/p/add-typedoc-api-support)

possible alternatives: docsify,