loosely connected to #25 (@zliu41 mentioned something similar)

Various tools across the Haskell part of the ecosystem support specific versions of the GHC compiler - having up-to-date dashboards showing which compiler versions are supported by which commits of a given tool or library (Plutus, Plutarch, Plutus-apps, etc) would be of tremendous help when making a decision to upgrade or when setting up key project architecture.

In particular, a roadmap that includes major releases of GHC beyond 9.2 would be helpful.

Cloud-development platforms usually provide a "well-architected framework" that describes their view of how to approach the development of complex systems on top of their platforms.

Here are some examples:

• AWS: https://aws.amazon.com/architecture/well-architected
• Azure: https://learn.microsoft.com/en-us/azure/architecture/framework/

In essence, each framework provides a set of best-practices on how to approach different development disciplines, such as: security, reliability, performance-optimization, monitoring, tracing, etc.

Having a "Cardano Well-Architected Framework" in a similar fashion to the mentioned above would serve as useful guidelines for developer teams entering the ecosystem.

Hypothesis: A quick and straightforward way to spin up a local testnet would positively affect the developer experience.

When looking at other blockchains, many - such as Hyperledger Fabric, Mina, Solana - have simple, reproducible steps to create a local testnet via docker.

Plutip appears to be the simplest solution at the moment, but with a nix build . as the initial step, I'd argue that there is still some work ahead of us if we wanted to create a local testnet on our machines.

Even if developing dApps on Cardano was easy (it's not), this initial hurdle is pretty big.
I would like to propose an effort to containerize infrastructure that goes beyond a cardano-node docker image.

The node-to-client mini-protocols are only available via unix-socket connections. AFAIK, the goal of this constraint is to reduce the attack surface, improving security.

Although valid, this approach limits the deployment options at the infrastructure level. A setup that includes Cardano Node, DBSync, Ogmios, Submit-API, etc forces the operator to merge the workload under a single host, which is far from ideal.

Allowing each component to run in a different hosts brings several benefits: horizontal scaling, high-availability, resource isolation, etc. Many operators from the community have relied on workarounds (eg: UNIX <=> TCP socat tunnels) to escape the constrained imposed by the Node.

On a private network topology, having a way to enable node-to-client communication via TCP would simplify configuration and introduce new deployment options. This option should be disabled by default and would require an explicit opt-in from the operator to enable it.

Over recent discussions, we've had attendance from Joseph Fajen, a technical writer at IOG, who requested topics for upcoming documentation focus. I've run a recent poll among my developers, and these were the most requested items:

Ideally, this short list can be something we add to incrementally

• A field-by-field explanation of Cardano transactions, updated for each era - so that constructing a transaction by hand from scratch is easier

• a field-by-field explanation of the protocol parameters and how we've arrived at the current parameters.

Key to Intersect’s core mission is its commitment to preserve and stimulate open-source development on Cardano. The Open Source Committee (OSC) will steward Cardano’s open-source strategy by formulating and deploying a comprehensive roadmap for open-source initiatives happening on the Cardano blockchain, ensuring that transparency and accessibility are always considered. Within Intersect, it serves as an advisory body to the Open Source Program Office, the OSC’s efforts will be guided by tenets aimed at maintaining an open-source culture across Cardano. At a recent meeting, the OSC agreed the following principles and aims:

(Legitimacy) Maintain the legitimacy of the Cardano Open Source Project (COSP). The COSP is not just a collection of GitHub repositories. It is the source code for the binaries that are deployed onto the real Cardano mainnet.

(Quality) Maintain the security and health of the Cardano mainnet. That means COSP must be committed to high quality, both in decision-making and in writing software.

(Sustainability) Development of the COSP must continue. Many open-source projects die: people lose interest, move on, knowledge is lost, etc. If that happens to the COSP, then the Cardano network may become stagnant.

(Citizenship) Be a good Open Source citizen. We want the COSP to be a model in the open-source world. That means taking the time to contribute to the broader ecosystem.

https://discord.com/channels/1136727663583698984/1158760831203430470/1167022775559520317

Currently, effective usage of Plutus in production pretty much requires reading of the Plutus specification and the extended EUTXO model. However these documents are not necessarily optimized for quick-reference in the ways a programmer may need, they're really intended for implementors and early integrations.

Additionally, a developer using Plutus will typically also make use of Haddock Generated documentation available for the Plutus Library or other related tool in Haskell.

This leaves a number of deficiencies in documentation:

• documentation should be searchable and discoverable through means that are convenient for developers (example: MDN
• users of alternative languages will often need to cross-check for specific parts of the plutus API (such as scriptcontext) - perhaps something akin to internationalization can be supplied in documentation to have equivalent code examples in multiple languages

Broadly speaking, the Cardano Ecosystem relies heavily on Nix.

While Nix can help lead a project to reproducible builds, it can make the process of upgrading dependencies very difficult to manage.

In other Ecosystems (Haskell, Nodejs/npm, etc), a 'constraint-solver' algorithm is used to determine the packages that are known to build together. Haskell's ecosystem has also produced 'Stackage' which creates sets of packages that are known to build together, this makes it easier for library maintainers to see when their library has lost compatibility with a particular package, and for users to know which of their dependencies may not be ready for an upgrade.

unfortunately this infrastructure is not currently available in the Cardano ecosystem. Two solutions are apparent:

• work on integrating the cardano ecosystem with the mainstream Haskell ecosystem in hopes of being included in Stackage nightly images
• create our own version of stackage or a similar toolchain/CI system to validate builds for developers.

the newly created cardano Preview and Pre-prod testnets bolster the developer experience. However traffic on these testnets is traditionally low. For developers to build robust software - they may need to test against sub-optimal conditions.

We propose a testnet that offers traffic simulations similar to the real Cardano network during high congestion times (or even beyond them to simulate the next surge of adoption).

when a new cardano network is constructed - there's no way to quickly acquire protocol parameters and settings to gain access to the network, instead a user has to search discord and documentation to find the correct settings. This would serve the greatest number of people the fastest as a trusted centralized service that could perhaps be decentralized in the future.

Being able to call an API to discover networks and their current valid parameters would make bootstrapping a node or network that much faster.

Choosing the right software quality attributes (SQAs) is crucial for a developer experience (DevEx) working group for several reasons:

1. Alignment with project goals: Selecting appropriate SQAs ensures that the developed software meets the project's objectives and user needs. By focusing on the right attributes, the DevEx group can prioritize efforts and resources effectively.

2. User satisfaction: High-quality software that excels in essential SQAs, such as usability, performance, and security, leads to increased user satisfaction. A positive developer experience contributes to higher productivity, reduced frustration, and long-term engagement.

3. Risk mitigation: Identifying and addressing critical SQAs helps minimize potential risks, such as security vulnerabilities, system failures, and poor performance. By proactively addressing these concerns, the DevEx group can reduce the likelihood and impact of issues that may negatively affect the developer experience.

4. Differentiation: Focusing on specific SQAs can differentiate the developed software from competitors, making it more appealing to developers. By excelling in areas that matter most to the target audience, the DevEx group can create a competitive advantage.

5. Efficiency and maintainability: Prioritizing SQAs like modularity, testability, and scalability can lead to more efficient development processes, easier maintenance, and lower long-term costs.

When choosing SQAs for a DevEx working group, consider the following factors:

• Stakeholder requirements and expectations
• User needs and preferences
• Project constraints (e.g., budget, timeline, resources)
• Technological factors (e.g., platform, tools, frameworks)
• Industry best practices and standards

By carefully selecting and prioritizing SQAs, the DevEx working group can create software that meets user needs, reduces risks, and fosters a positive developer experience. Regularly reviewing and updating SQAs ensures that the group stays aligned with evolving project requirements and user expectations.

Plutus was originally released with PlutusTx as the default Haskell API for building plutus onchain scripts. other tools have quickly emerged for writing plutus without Haskell, either as a standalone language, or as an embedded DSL in mainstream programming languages. Additionally, other tools have arisen for building transactions offchain in multiple languages. A problem that then arises from this plethora of choice is sharing types and interfaces across languages for convenience, and in the case of Haskell alternatives, there has been compiler compatibility issues that can make certain alternatives harder to use.

Smart Contract Languages (Onchain Scripts)

• PlutusTx, Haskell*
• Plutarch, Haskell*
• Pluto, Standalone
• Helios, Standalone
• Aiken, Rust/Standalone
• Imperator, Standalone
• plu-ts, Typescript/Javascript

Transaction Builder Toolkits (Offchain Code)

• PyCardano, Python*
• PAB, Haskell*
• plu-ts, Typescript/Javascript
• decentralized application backend (DAB), API-based - this may qualify as more of an indexer/tx subscription service without an API that covers both indexing and submission.
• cardano-transaction-lib, Purescript (Javascript/Typescript coming soon)*
• lucid, Javascript
• mesh, Javascript

** known to be used in production, or have large plutus projects actively adopted for production purposes

Cardano has a flourishing polyglot suite of tools, however there are going to be a number of gaps when attempting to compose these individual tools into a full-fledged application:

• type sharing between smart contract and Transaction builder layers
• currently there is no known implementation of these tools for platforms that target mobile or gaming/metaverse technology. the best offering here is currently javascript, but it would be great to see similar tools for in C#, Dart, Golang, Swift, etc.

Dealing with concurrency on Cardano is something that most dapps and protocols have had to contend with due to the nature of utxo. There exists some local state and more than one actor wants to mutate that state at the same time.

Traditionally, this has been solved by each dapp one of two ways.

1.) Fragment the utxos so that each actor has a better chance of getting their own view of the world to complete their transaction. This is complex for a developer to implement, still results in some collisions of actors, and doesn't scale well due to the added costs of maintaining a large set of utxos.

2.) Utilize a "batcher" approach. Each actor submits an "order" transaction that represents their desire to complete an action on the protocol. Later, the protocol operator or a federated group of batchers bundles up the orders and executes them as a group against the protocol.

On other blockchains that are not utxo-based, an account-model has no issue with concurrent transactions as they have global state. Every protocol having to manage a huge list of utxos or find a way to pay decentralized batcher/scooper operators. This is a reason to pick other chains instead of Cardano. For example, WorldMobile picked a cardano sidechain based on Cosmos.

One idea I had to solve this issue is to create a CIP for Smart Transactions™.

A Smart Transaction contains input and output utxos just like a standard transaction. However, some of the input and output utxos are not fixed at submission time, but are instead resolved while the transaction sits in the mempool. Instead of a hash#index for an input utxo, it is defined as a criteria object.

A Criteria object contains an address bytearray. This will cause the mempool to find a utxo that must be assigned to that address. Additional fields can be added to this criteria to match on amount of ada (exact, less than, greater than, between). Another field could be added to match a utxo containing specific inline datum values. There also needs to be the concept of capturing datum values as variables that can be used on the output side of the smart transaction.

The cardano-node is already validating transactions in the mempool. Whenever a new block arrives, transactions that exist in that block are dropped from the mempool. Also, any mempool transaction that has passed beyond the TTL value becomes invalid and is dropped.

What Smart Transactions proposes is to add additional validation to see if there exists any utxos that can be gathered to make a valid transaction. If it ever happens that a valid transaction cannot be built based on a transaction's criteria, it will be dropped from the mempool. If a valid transaction can be constructed from utxos in the virtual mempool ledger state, they are added to new areas outside of the body of the transaction. So a Smart Transaction contains criteria utxos, smart output utxos, and an area of what utxos got resolved by the mempool.

On the output utxo side, there needs to be some flexibility so that an output utxo can have a computed amount of ada, native assets, and datum. I'm not sure exactly how to implement this piece, but we need to support certain capabilities such as take an input datum integer value, increment it and apply it to the output datum. Maybe snippets of plutus code could be used for these capabilities.

At the end of the day, we need to have the capability for two actors to put in a Smart Transaction that interacts with a smart contract, doesn't specify exactly which utxos on the contract it uses, but instead specifies what a utxo must look like to be used. Then, if both come in at nearly the same time, the second one ends up selecting utxos from the output of the first one. Both are placed successfully into the mempool as chained transactions.

There are likely some security implications to this to ensure it cannot be overly abused. Users might need to be warned whenever a criteria is selecting an open-ended utxo from an address in their own wallet. This also introduces the possibility that pool operators could engage in front-running. We would need to decide on whether this type of capability is useful enough to overcome these issues. I personally think this would open up Cardano to be able to build any type of protocol or dapp that is currently possible on other blockchains without resorting to batchers or cost-prohibitive architectures.

There has been some discussion about open source example dApps - especially as templates that can be forked and used by developers to write something quickly.

These serve as examples of best practices, code organization, and also help the user overcome the host of problems that can arise when trying to assemble individual tools into a working dApp.

Some existing e2e example dApps:

• Seabug
• cardano-marketplace

Other open source Smart contracts users can use as examples:

• jpeg store contracts

I want to draw attention to some CIP's that would offer significant improvements to the developer experience - and a short description of what those changes will be.

at the end i also include some efforts that do not yet have a drafted CIP, but have been part of discussions and may soon receive a CIP of their own.

• Plutus Script Type Uniformization - Currently, a great deal of indirection is necessary in order to do stateful minting of tokens, something as simple as counting the total minted tokens requires multiple scripts. This would allow the various script types to be composed into a single script, bringing Cardano smart contracts closer to the notion of smart contracts from other ecosystems, which can mint or hold tokens while managing internal state.

• Bitwise Primitives for Plutus - This allows for efficient computation on chain - as may be relevant for data structures, cryptography, and Zero-Knowledge-Proof verification, similar to most other languages.

• ECDSA and Schnorr Signature verification in Plutus - This adds a new efficient cryptographic curve primitive to the plutus language - these signature schemes are heavily used within the Bitcoin and Ethereum ecosystems for transaction signing and certain varieties of Zero-Knowledge-Proof. This primitive can make protocol interoperability much easier, especially for bridge and cross-chain protocols

• Preserve the Submitter's Ordering of Transaction Inputs - This simplifies the developer's experience when writing smart contracts. When preparing a transaction off-chain, the submitter (or rather, the developer writing the tx building code) can make certain assumptions about the ordering of UTXO inputs to the transaction, which are not currently respected onchain. simplifying this allows the onchain code to be slightly more efficient, and more intuitive when compared with the offchain code that generates it.

Honorable Mentions include two efforts for which there is not currently a CIP, but may be viable for plutus v4:

• Atomic Multi-transactions for composable non-custodial financial transactions
• Input endorsers adjustments for patterns that can improve offchain transaction building.
• Now that blockfrost is open source: a blockfrost registry (similar to the Freeloaderz submit-api registry)

These represent next steps to reducing the stumbling-blocks of working with Plutus from any language/APi (PlutusTx, Helios, Plutarch, Pluto, etc), which require changes the the language version or the ledger. However there are a number of efforts which do not require changes to Cardano in order for them to succeed and be beneficial:

• Smart Contract Blueprints - This creates a standard for programmatic discovery of a smart contract and easily inspecting its interface.

PLEASE don't drop support for nix.

Hearing rumors that IOG is considering deprecating their Nix support. I just want to put my vote in that I will be dropping out of the Cardano ecosystem altogether if that's the case. Cardano is tough enough as it is..but Nix makes everything easier once you understand it. The problem with using nix in this ecosystem is not Nix. It is the lack of documentation around Cardano's use of nix which I am working independently to rectify.

A purpose of this group is to support newcomers.
Multiple alternatives are available, but we can't support each.
We must consider tradeoffs and affected stakeholders.

• describe stakeholders
  • personas and
  • stories.
  • values.
• Review the list of plutus-starter alternatives (see below) and rank them on the order of who will be getting support first.

Questions:

• What are the alternatives to plutus-starter?

  • #22
  • #21

• how do we measure impact and efficiency?
  Time to market, time to productive,

• How do we rank and prioritize work packages to maintain such resources?

  • (weighted) number of potential users per projected ADA spent on maintenance per year.

• What do we value?
  #75

Originally posted by @aleeusgr in #72 (comment)

Several tools in the Cardano developer ecosystem rely on direct access to the node using Ouroboros mini-protocols. Most of the wire-format is fully defined by the spec, except for certain messages which are specific to the Cardano ledger implementation.

In particular, ATM, we lack information regarding:

• the "Local Tx-Submission" mini-protocol specification skips the definitions for the rejection reason message.
• the "Local State Query" mini-protocol specification skips the definitions for the query and result messages.

Several teams attempted to reverse-engineering the Haskell code or intercept wire data to infer the CBOR structures. This is a complex and error-prone process that doesn't scale. On top of that, each cardano-node version might potentially change / augment these definitions.

This is an example of a community-driven effort to document the local-state-query mini-protocol:
https://arsmagna.xyz/docs/network-lsq/

Having a well-documented and up-to-date spec (message flows, CDDL, etc) would simplify the process of building & maintaining client libraries and tools for low-level interaction with the node.

A key problem for developers is about getting accurate and reliable execution units for a transaction. Some known issues:

• Balancing and Resource Estimation is somewhat mutually recursive. Balancing can increase the UTXOs, which increases any iterations over the utxos, resulting in greater resource usage, resulting in more fees, etc.
• signatures need to be applied so that any looping over the witness set is also consistent, the signatures are then invalidated when the transaction is balanced, necessitating re-applications of cryptographic signatures as well.

it would be great if this process could be simplified.

https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

is a software quality standard. It describes the models, consisting of characteristics and sub-characteristics, for both software product quality, and software quality in use together with practical guidance on the use of the quality models.

test description

https://cardano-foundation.github.io/state-of-the-developer-ecosystem/2023/

• add working discord invite

API breakage is VERY common across the suite of tools being used to build Plutus Apps

it would be great if there was a common resource that at least made a record of API changes across dApps, and suggested common fixes for these. In an ideal case, we could produce scripts that will automatically perform code updates to fit API breakage.

This could dovetail nicely with reliable build solving - as it would allow a community API management team to document upgrades that would be ill-advised for individual developer teams.

This is work that could save a lot of companies piles of money, the amount of time spent on dependency upgrades can get pretty staggering.

Why?

plutus starter is deprecated (see Docpage)

what needs to be done?

• merge
• Docpage should refer to iogx as well.
• close
• close

When Michael Peyton Jones attended the Working group meeting on Nov 1 to discuss future GHC support, the question was brought about communicating deprecations to users. Currently the IOG ecosystem (and the broader ecosystem as a whole) does not have a consistent system for communicating deprecations to developers either ahead of time or upon release.

After some high level research at options, I've arrived at the following suggestions

1. Github releases for deprecations in the CURRENT commit (as MPJ suggested, they can be followed via RSS feeds)
2. Pre-emptively creating a github issue to disclose the deprecation (and as a resource that can be linked directly from the below options)
3. keep a section in the readme on upcoming major changes (with a link to the pre-emptive issue)
4. DEPRECATED Pragmas (in the case of GHC support, this can be combined with CPP)

This would allow developers to be notified of the deprecation when looking through issues, at build time, or when investigating the repo directly, which is MUCH better than nothing, and i think all that could be asked.

I'd like to discuss this a bit more at the next Developer experience meeting, but this seems sound and reasonable to me.

• Add contributing guide (WIP in Certification WG)
• describe state of devex
• describe perfect devex
• #28
• https://github.com/IntersectMBO/essential-cardano/blob/main/essential-cardano-list.md
• #81
• notes on wg governance

currently the iohk discord is very crowded and the registration steps necessary create a lot of barrier to entry for developers getting involved with the working group. i suggest we use the CIP editors as an example and move to a seperate server, which we can use for discord-based meetings and agenda management.

Currently the intersect gitbook page shows nothing about the working group.

TODO:

• visit the editorial.
• write edits and send them for review.
• confirm the edits are approved.

The necessary information can be found:

• WG Readme
• WG Charter

If in doubt read the volunteering guide

But thanks to Randall Harmon for being the champion.

https://docs.google.com/document/d/1RLIfX_wZzIe4x9xDYngvX1FvP5xg9wqYt0uyMHc7Zrw/edit

Should split the grants: Admin fees to to Open:Ecosystem and Milestones to Open:Developers

Suggestion from Cardano Developers Russia, from a wallet product owner

I am seeking more information to describe the issue better.

proposition: Writing plutusTx should not require advanced Haskell knowledge - as Haskell2010 has many resources for learners, and advanced features such as the use of Singleton types or TemplateHaskell should not be necessary

Empowering open-source contributors through business-friendly licensing involves adopting permissive licenses like MIT, BSL or FSL.
Clear licensing terms attract more contributors, reassure businesses, and promote a healthy ecosystem by balancing openness and commercial viability.
Regularly engaging with the community, providing support, and promoting transparent governance also enhance collaboration and contributor empowerment.

• https://en.wikipedia.org/wiki/Business_models_for_open-source_software