Mops is a package manager for Motoko with an on-chain package registry.
Mops includes essential tools for Motoko developers such as a test runner, benchmarking tool and toolchain manager.
Mops aims to empower and simplify Motoko developer experience.
Mops has extensive features such as package documentation, documentation coverage, package release notes, dependencies changes, package tests, benchmarking results, regression of benchmarks between versions.
Mops has been around for 3 years now and has gained recognition with ~210 unique packages and ~500k downloads.
Motivation
Mops is a public package registry that many developers rely on, and its decentralization is necessary, useful, and a great use case for the SNS.
The ICP funds raised through the decentralization sale are intended to fund the future development and maintenance of the Mops.
Fully on-chain
Mops CLI builds, package source files, package explorer, documentation, blog - all hosted on the Internet Computer blockchain and will be controlled by the Mops DAO.
There is no roadmap that spans for years. New features will be implemented depending on the user demand and/or the feature is worth implementing because it simplifies and/or improves Motoko developer experience.
The near future roadmap:
Implement a Mops DAO portal on mops.one to improve visibility of the DAOâs functioning
Implement a Motoko snippets REPL to quickly try out any package using in-browser Motoko interpreter which also makes it possible to run examples in the packageâs readme and documentation. Possibility to embed a snippet(like https://embed.motoko.org). Save and share snippets.
Fuzzy search in package docs page
Ability to deprecate and unpublish a package
Package docs: click to go to definition
Auto-check if newer mops cli is available
Dependency version ranges support
Implement Motoko build system (mops build command)
Auto-post to X/Telegram when new package/version is published(with changelog)
mops add command interactive search and add packages
mops update command interactive select packages to update
Store compressed tarballs instead of individual files
Registry index on GitHub
Eliminate dependencies with native bindings from CLI
People can add value to it, why not market it as meme. If someone buys a lot, than that person can just make X account and call MOPS as memetoken.
MOPS monster:
Would be great if Mops becomes SNS. Better security. You can also make it a Deno js script hosted in a DAO governed canister, making supply chain attacks near impossible.
I would change the params to:
Min to raise: 5,000 ICP (So the DAO has enough to pay the cycles costs for a while)
Max to raise: none
Min per user: 100 ICP
Max per user: none
With your current settings and giving 71% to the swap, it means someone can buy a lot with a script and then take the rest of the treasury out. (NF usually protects from that, but there is no NF here)
You could also put 33% into the âteamâ, maybe temporarily until you are sure swap was decentralized, then burn some if needed. Perhaps reduce max dissolve delay to 4mo, put all dev neurons at 4mo.
The airdrop neurons - I suppose these are the mops principals, will be hard to vote with right after the sale, so they canât really help.
Dissolve delay bonus set 20% and not 100% is better against a possible attacker that instantly after the swap will increase it to max and gain more vp.
When you put max per user, you are allowing scripters to take as much as they want, while the UI participants are limited to 1,000 ICP
I am not sure if SNS parameter changes require critical proposals now. If not - reduces the amount of tokens needed for attack.
You should guard against the scenario:
Someone gets enough tokens, locks them for max, changes paramethers, gets more vp, takes the treasury out.
Gets enough tokens, locks for max, takes treasury out
This can be scripted and proposals made right after distribution where others canât react quickly enough.
The attack wonât result in too much ICP lost with your maximum (maybe 5k ICP) but the SNS will be ruined. Best not to give that scenario a chance imo.
Iâm not sure if Caffeine uses Mops directly, but imagine tens of thousands of apps relying on it. If someone gains control over the Mops canisters, they could change a library and potentially launch a supply chain attack - draining DEXes, escalating privileges, or worse. Realistically, nobody audits all the library code every time they run mops install; doing so daily would be prohibitively expensive. Putting these canisters under SNS control would significantly reduce that risk and make such attacks much harder. In that sense, it could even give Motoko an edge over Rust.
Ethereum validators arenât upgrading all apps, only the layer that runs them.
The âInternet Computerâ is not made to govern 10 apps, but host thousands of apps governed by different people.
Ah so a 51% attack on the code the apps run on is not a concern for us to worry about?
I figured with the history of daos being taken over this specific sns sale would be a big risk for people using the code themselves.
From what I read this helps streamline motoko development which is why it wouldnât be the worst idea to avoid a potential 51% attack and just let the nns govern it.
Would be a shame if a code base that people use to deploy projects gets 51% attacked. There should be no issue in discussing if there is a better path forward here.
But what do token holders get out of holding or staking the token? Theyâre not going to hold it at a cost to avoid a governance attack on something that doesnât make them any money (being realistic).
The reason I was asking is because tokens that donât benefit holders will get sold, and will be cheap. Theyâll be bought up by the devs or whoever else wants majority control. @Mico has a point.
If thereâs no revenue model or means of sharing benefits to DAO members, then this project isnât fit to be an SNS in my personal opinion.
In this context it would be a recipe for inevitable centralisation, a community of investors who feel let down, and funds that are extracted for devs to dev (this SNS would only benefit them, in financial terms - which is the opposite of what an SNS should be).
I think we cannot be sure that swap was decentralized. Someone may be using multiple addresses, or there may be a group of people acting in collusion. It might look decentralized, and when I reduce the teamâs stake, an attacker might start doing bad things.
Yes, it is set to 20%
Sad, if there is no protection on the NNS/SNS side against this. This makes âMax per userâ parameter useless.
Unlimited âMax to raiseâ makes SNS sale less attractive. I think in this case some other limit should be set, say only 12h or 24h sale duration.
Unlimited âMax per userâ gives good and bad actors a chance for equilibrium.
Initial small and limited âMax to raiseâ was chosen to make it less attractive for attackers to take over control of raised funds. In addition the Community Fund is not involved here, so itâs even less attractive.
Revenue-sharing isnât the only viable model. In fact, most crypto projects do not reward holders through revenue sharing.
For example BTC, ETH, SOLâŚ
ICP also does not make profits or share them with holders.
ICP has utility. Tokens are burned in order to pay for compute. Therefore, assuming a successful IC long-term, ICP should become deflationary (at which point holding ICP is implicitly beneficial for the holder in financial terms, and therefore staking even more so). Thereâs clear utility and long-term financial incentive.
Weâre not talking about BTC or other leading tokens. Weâre talking about an SNS project which is raising funds to pay developers with no plans to benefit those investors. In my opinion, these sorts of SNSs only feed into the negative perspective that many investors hold about IC SNSs.
There needs to be a plan to secure the governance tokens. This can only be achieved by giving them tangible value, or making supply sufficiently scarce by other means (but without centralising ownership of the tokens).
At its current stage, I would plan to reject the SNS launch proposal, and I would strongly suggest that others do too.
@ZenVoich Thanks for all the work you have done to move Motoko forward. I remember it being a huge improvement over vessel. It has become the standard in package management and that is a testament to the work you have put into the project. Looking forward to the sale.
SNS - Service Nervous System - made to govern decentralizedservices.
Mops - a service for developers
Mops benefits from decentralization, no supply chain attacks, no DoS attacks
IC benefits from Mops - more developers, more apps developed, more cycles burned
The MOPS token could be required to publish packages - this will make the services DoS resistant. Right now, if someone attack them, they will bring Motoko development to a halt for a while.
Sounds a bit like âtragedy of the commonsâ scenario. MOPS could monetize one day, if IC and Motoko gain mass adoption, sure. Right now the MOPS burned should just be enough to pay cycle costs.
There are other services it can get into - bug bounties, audits, hackathons, etc. @ZenVoich could just get funded with Dfinity grants, since this is part of the IC stack. While the DAO turns more into an airdrop that decentralizes the service and we hope devs arenât that desperate to sell their voting power for few bucks.
