Forem: Lauren Lee

Midnight network is live

Lauren Lee — Mon, 30 Mar 2026 14:28:04 +0000

The Midnight network is officially live. This milestone marks the introduction of state continuity and permanence in the network and is a significant achievement for everyone involved. This launch follows years of research, development, and collaboration to develop the fourth generation of blockchain technology to deliver end-to-end privacy that is flexible and enforceable at the protocol level. Scientists, engineers, developers, partners, and the community all made substantial and ongoing contributions to the development of the network from its inception.

The genesis block marks both a culmination of building toward the network launch and the starting point for the next phase of on-chain network activity. Developers, partners, and institutions will be able to deploy applications and migrate assets on Midnight. This launch triggers the next stage of network and ecosystem expansion as more Midnight-native tools and services come online that will enable end-to-end programmable privacy.

Scaling real-world use with fourth-generation blockchain

Midnight, the world's first fourth generation of blockchain addresses the fundamental barriers that have prevented blockchain from supporting the real world at scale. Applications in the real world require the ability to protect sensitive data, execute compliance logic on-chain, and make blockchain as accessible as any other technology. Midnight is designed to solve all three.

Outlining the journey and roadmap from the first bitcoin transaction to Midnight’s fourth-generation technology, Founder of Input Output Charles Hoskinson explained how we got to the fourth generation of blockchain: "Satoshi gave us good money; Ethereum gave us programmability; Cardano brought the third generation of interoperability, scale and good governance. Midnight gives us our identity and privacy back”.

While the previous generations of blockchains achieved scale and programmability, and sparked waves of innovation, they did so on public ledgers. This is why the vast majority of the world’s value remains off-chain. Trillions in real estate, private equity, debt and currency cannot yet be digitized. The lack of privacy and unpredictability of the infrastructure makes digitizing and tokenising their assets an existential risk to institutions and the value they hold.

Midnight can remove the final hurdle to bringing the world’s economy on-chain. Midnight gives everyone the capability and opportunity to digitize all the world’s value.

Unlocking Real-world privacy

For blockchain to support regulated activity, on-chain privacy must be programmable. Midnight allows developers to determine when to apply privacy across both application and transaction layers. This is achieved through a technical architecture that prioritizes data sovereignty and cryptographic verification:

Hybrid Ledger Architecture: Midnight uniquely combines both public and private data, enabling applications to process and verify sensitive personal, financial, and commercial information without the data ever being exposed to the network.
Client-side proofs: Sensitive data stays on the user’s device where it belongs. Using a local proof server, zero-knowledge proofs are generated on the user's machine and submitted to the network for validation, meaning identity, eligibility, credit, and compliance verification can happen without the underlying data ever leaving the user's hands.
Shielded & Unshielded Assets: Midnight introduces shielded and unshielded assets, giving developers flexibility over if information is shared on-chain. Shielded assets keep balances, counterparties, and transaction flows off the public ledger. Unshielded assets provide the tools for open collaboration and exchange. Confidentiality and auditability are not a choice between one or the other — on Midnight, you have both.
Selective Disclosure: Compliance logic can be programmed directly into an application, defining exactly when transaction information must be revealed and to whom. Authorised participants including counterparties, auditors, regulators can be granted visibility into specific records without accessing the underlying data that initiated the transaction. This feature enables identity verification, regulatory checks, and eligibility conditions to be validated on-chain without exposing the underlying data. Abstracting away the underlying zero-knowledge cryptography, Midnight empowers developers to focus on application logic while providing users with real-world privacy.

Sustainable costs and predictability

Token volatility makes existing blockchain infrastructure commercially unworkable for many real-world use cases. Transaction fees paid in a network's native asset expose operational costs to market price movements, preventing businesses from accurately forecasting operational costs.

Midnight architecture resolves this through a dual-component economic model. Separating the asset used to govern and secure the network from the resource used to pay for transactions ensures operational costs remain predictable. The Midnight network opens up a path toward a future where users no longer need to hold or manage volatile crypto assets to use the network.

Aligning incentives with dual-component tokenomics

Midnight uses a dual-component economic model designed to align the incentives of users, builders, and validators.

NIGHT for utility and governance

NIGHT is the generator for the network’s operational resource, DUST. NIGHT is the unshielded ledger-native governance and utility token. NIGHT generates the DUST resource, which means NIGHT functions as a store of value for the ecosystem without being consumed by daily transactions. NIGHT is also intended to grant governance rights to holders.

DUST is the renewable network resource

DUST is the resource required to power transactions. Unlike traditional gas models where tokens are burned or paid out, DUST operates on a recharge model similar to a battery.

Generation: DUST is generated proportionally to NIGHT holdings. A NIGHT holder can register NIGHT to generate DUST and designate a recipient to power transactions on the network. That gives NIGHT holders flexibility to choose how to designate their DUST resources.
Sustainability: DUST regenerates over time until it reaches capacity based on the amount of NIGHT held. It takes seven days for a DUST address to reach full charge, whereas partial recharges take proportionally less time.
Self-funding applications: Developers can hold NIGHT to generate the DUST required to cover transaction costs for their users. This allows for applications where the end-user does not need to own or even be aware of the underlying tokens to interact with the service.

Abstracting away complexity with Compact programming language

To make advanced cryptography accessible, Midnight uses Compact, a statically-typed domain-specific language (DSL) based on TypeScript. Compact allows developers to manage both private and public states within a single contract. By using familiar syntax, the language removes the requirement for specialized expertise in ZK proof cryptography, enabling more efficient development of sophisticated logic.

The design of Compact focuses on lowering the technical barrier to building privacy-enhancing technology. Learn more about Compact in the Midnight documentation.

Launching alongside leading institutions

The Midnight network launch represents the primary milestone of the current development phase, which focuses on strengthening infrastructure and achieving operational stability and security. During this stage, the network expands to include distinct federated node operators that collectively operate the protocol under explicit rules for participation and coordination.

While these operators already support the Midnight Preprod network, their participation in the Midnight network launch provides the secure, enterprise-grade foundation necessary for live applications to function. By involving leading global institutions, the Midnight Foundation ensures that infrastructure is managed by operators with proven experience handling high-volume, mission-critical data.

Charles Hoskinson explains, “Midnight is the first public blockchain that gives the world the infrastructure it needs to come on-chain — without sacrificing privacy or compliance. Launching alongside partners like Google Cloud and MoneyGram is a monumental step. For the first time, organisations of this scale have committed not only to running critical infrastructure but also to building and deploying live applications on a public network.”

Learn more about the federated node partners supporting the network including Worldpay, Bullish, MoneyGram, Pairpoint by Vodafone, eToro, AlphaTON Capital, Google Cloud, Blockdaemon, and Shielded Technologies.

Multiphase roll-out strategy for stability and security

The rollout of the Midnight network from genesis block follows a structured multi-phase path to decentralization, and will begin with an initial phased application deployment rollout period to ensure operational stability and security. This is essentially an early phase where developers and applications can access the network’s functionality within a protected environment.

This structured approach allows users to have more confidence that the early DApps and services launching on the network are from developers who have met rigorous readiness criteria.

To maintain this security during the initial phase:

Development best practices: The Midnight Preprod environment is a mirror of the Midnight network. As is common development best practice, all developers should test and deploy to the Preprod environment first to ensure application logic is fully optimized before moving to production.
Infrastructure resilience: Federated node operators are protected by a private protected network. This architecture creates a secure, encrypted communication layer, making the network's core infrastructure resilient against potential external attacks. Fahmi Syed, President of the Midnight Foundation explains the multiphase strategy: “This rollout will be phased, reflecting the importance of introducing privacy-enhancing infrastructure in a deliberate and resilient way. More importantly, this creates the foundations for an entirely new class of on-chain activity. When privacy is built into the system itself, it becomes possible to bring real-world activity and assets on-chain without exposing the underlying data — unlocking entirely new forms of economic value that were previously impossible on transparent infrastructure.”

Progressive decentralization

As stewards of the network, the Midnight Foundation intends to transition from this federated model to a fully decentralized network. This path to decentralization is designed to be managed thoughtfully and responsibly, ensuring the network maintains security and stability as it matures. This planned evolution allows the ecosystem to scale while moving toward a fully decentralized and permissionless state in subsequent phases of the roadmap.

What to do next…

The Midnight network launch is a significant milestone that initiates the next phase of ecosystem growth. This release provides the foundation for a wide range of privacy-preserving applications and institutional integrations.

See live network metrics at Midnight Explorer.

Join the community on Discord.

Check the Midnight blog regularly for more news and information.

Get your project on the map

Lauren Lee — Fri, 06 Mar 2026 12:40:58 +0000

Three quick updates to make sure your work is visible, counted, and recognized as part of the Midnight ecosystem.

Why this matters

Midnight is approaching mainnet. The ecosystem already has hundreds of active developers building with Compact, deploying on Preprod, and shipping real applications. But activity that isn't attributed doesn't get counted, and that invisibility has real consequences for the ecosystem you're helping to build.

Establishing a clear public record of development activity ensures that the broader blockchain industry recognizes the growth of Midnight Network. Accurate attribution is a functional necessity for the ecosystem and establishes a standardized framework for documenting technical contributions.

The attribution process

Electric Capital produces the most widely cited developer report in blockchain. Investors, protocols, and media use it to understand which ecosystems are growing, which are stagnant, and where to pay attention. Their methodology is public: they track GitHub commits, contributor counts, and repository metadata across every major blockchain ecosystem. If your repo doesn't have the right metadata, their tooling won't associate it with Midnight, regardless of how active or high-quality the work is.

Midnight is submitting its ecosystem map to Electric Capital for the first time, ahead of mainnet. This is a one-time window to establish a credible public record of where the ecosystem stands from day one. Developer counts from the weeks surrounding a mainnet launch are captured in a rolling window that informs how new ecosystems are ranked and covered. Ecosystems that show up in that window with strong numbers get recognized. Ecosystems that don't, start from a deficit they spend months correcting.

Compounding developer results

The changes below take under five minutes per repository. They are small, permanent, and consequential. Beyond writing code, implementing these metadata standards is a high-imact action for ecosystem growth. Every repo that completes them is a developer who gets credited for building on Midnight.

TL;DR: Midnight's developer ecosystem is real and growing. These three steps make sure that growth is visible to the tools and reports that the wider industry pays attention to.

Step 1: Add GitHub topics

GitHub topics are how Electric Capital (and other ecosystem trackers) programmatically identify which repos belong to which ecosystem. Without them, even actively maintained repos are invisible to the tooling.

To add topics to your repository:

Go to your repository on GitHub
In the right-hand sidebar, find the About section
Click the ⚙️ gear icon next to it
In the Topics field, add the relevant topics from the table below
Click Save changes

Topic	When to use
`midnightntwrk`	Required for all Midnight ecosystem projects
`compact`	Add only if your project uses the Compact language

Do not use: midnight, midnight-network, midnight-compact, or midnight-ecosystem. These variants are not tracked and will not associate your project with the ecosystem.

Step 2: Add one attribution sentence to your README

Electric Capital's tooling scans README files for signals that confirm a repo's relationship to an ecosystem. One sentence, placed near the top of your README, is sufficient. Please use exact wording from the table below. Customising the phrasing means the automated system may not recognize it.

Your project type	Attribution sentence
dApps, contracts, or tooling that run directly on Midnight	"This project is built on the Midnight Network."
SDKs, infrastructure, wallets, or services	"This project integrates with the Midnight Network."
Developer tooling, frameworks, or libraries	"This project extends the Midnight Network with additional developer tooling."

Step 3: Open a PR to the Awesome dApps list

The Midnight Awesome dApps list is the community-maintained directory of ecosystem projects. Opening a PR adds your project to that record and makes it discoverable by other developers, partners, and the teams evaluating the ecosystem.

Submit your project at: github.com/midnightntwrk/midnight-awesome-dapps

Earn Zealy points while you're at it!

Each of the three steps above has a corresponding quest on Zealy. Complete them to earn points and appear on the Midnight ecosystem leaderboard. Links to the three quests are below.

Quest 1: Add the midnightntwrk GitHub topic
Quest 2: Add the attribution sentence to your README
Quest 3: Open a PR to the Midnight Awesome dApps list

Three steps, once per repo, permanent record

These changes don't affect how your code works. They affect how your work is seen. Midnight's first public developer count will be used in every industry report, investor briefing, and ecosystem comparison that references the network for years to come. Your repo being in that count matters.

Questions? Find us in the Midnight Discord in #dev-chat, or reply to this post.

Aliit Fellowship Now Accepting Cohort 2 Applications

Lauren Lee — Thu, 05 Mar 2026 14:48:25 +0000

The Aliit Fellowship, the technical contributor program for the Midnight network, is now accepting applications for Cohort 2. Cohort 1 is active. The program has evolved. Here's everything you need to know before you apply.

The Aliit Fellowship serves as the primary hub for hands-on contribution to Midnight. The Aliit prioritizes technical expertise and ecosystem development. Fellows engage directly with the protocol, create essential tooling, and produce the documentation required to make zero-knowledge (ZK) technology accessible. Alongside core development, the Fellowship includes dedicated tracks for Education, Advocacy, and Community Leadership which are inclusive of different types of contributions.

Following the successful launch of Cohort 1, the Fellowship has transitioned to a rolling admission model to better integrate contributors as they ready their projects. Applications for Cohort 2 are now open.

About the Aliit

The Aliit is Midnight's technical fellowship. It exists for developers who are actively contributing to the ecosystem in meaningful, hands-on ways, whether through code, tooling, documentation, support, or other technically grounded work.

The Aliit Fellowship focuses on the technical development of the network rather than social or community reach. While the Nightforce program supports community growth and visibility, the Aliit supports contributors who strengthen the technical core of the ecosystem.

The Aliit Fellowship is looking for contributors who operate with good technical judgment, communicate clearly, and are willing to help unblock others. This Fellowship is built on trust and responsibility.

The Candidacy Structure

The Aliit Fellowship now runs on a four-stage path:

Candidate is where you begin. This is a two-month phase structured within Zealy, with updated quests designed to surface how you think, what you build, and how you show up for the community. Applications to become a Candidate are reviewed on a rolling weekly basis. You can apply to become a Candidate at any point.
Tier 1 Fellow is the entry point for the Fellowship. If you're accepted into Cohort 2, you’ll become a Tier 1 Fellow. Cohort 1, which graduated from Cohort 0, are already Tier 1 Fellows. This stage is a four-month commitment, and it's where you'll establish your rhythm of contribution and build alongside the existing Fellows.
Tier 2 Fellow runs for six months and carries you through the end of the year. Members who progress to Tier 2 have demonstrated consistency and are embedded more deeply in the work of the ecosystem.
Tier 3 Fellow opens in January 2027. We'll share more about what this looks like as the year develops.

How Contribution Works: The Four Personas

One of the most significant changes in this iteration is the introduction of contribution personas. Rather than prescribing a single mode of participation, we've defined four lanes that reflect how real technical contributors actually work.

Builder is the default for every member. This covers development work, tooling, protocol contributions, and anything living in GitHub.
Educator is for members who create tutorials, run workshops, write documentation, or help other developers understand complex concepts. If you're the person who makes ZK proofs feel approachable, this is your lane.
Advocate covers talks, content creation, and activities that bring new developers into the Midnight ecosystem. If you're actively representing Midnight at events or through original content, this is where that work counts.
Community Leader recognizes members who organize events, provide ongoing support in developer channels, and help coordinate the broader builder community.

You're not locked to one persona. Each month, you self-report where your contributions landed across as many lanes as apply to you. The reporting is lightweight: GitHub activity plus a monthly summary, nothing more.

Benefits of Fellowship

The Fellowship provides resources and benefits tailored specifically to technical contributors. Candidates receive access to an exclusive Discord channel and an NFT while in the queue. Fellows receive a package designed to support technical, personal and professional development alongside ecosystem growth including: welcome swag, developer tool credits, NFTs, dedicated Discord access, community spotlight opportunities, fireside speaking slots, public speaking coaching, and conference credits.

The further you progress, the more the Fellowship supports your ongoing development . Tier 3 Fellows will receive NIGHT rewards on top of all other benefits. More details on that will come as mainnet approaches.

How Admissions Work

Applications are accepted on a rolling basis and reviewed weekly. There is no batch deadline. If you're ready, you can apply now.

During the Candidate phase, we're paying attention to how you engage with the updated Zealy quests, the quality of your contributions in Discord and the developer channels, and how you show up for other builders. Admission decisions reflect that whole picture.

Once accepted into Tier 1, you'll receive an onboarding from the team and be connected with the existing Fellows. The program is designed to be genuinely collaborative, not just a credential.

This program was built because Midnight is early, complex, and evolving. The Aliit exists to catch issues early, improve clarity, and help other builders move forward. If that kind of work is what you're already doing, you belong here.

How to apply

The admission process operates on a rolling basis, with Candidate applications undergoing regular review. The first formal review of this Candidate pool occurs at the end of April, with official onboarding for Cohort 2 beginning on May 1.

Early application ensures candidates have sufficient time to establish a record of contribution before the April review.

If you have questions before applying, drop them in the Midnight Discord. The Fellows and the DevRel team are present and responsive.

Apply to be part of Cohort 2 here.

DevRel When the Ecosystem Is Still Taking Shape

Lauren Lee — Mon, 02 Feb 2026 07:22:01 +0000

What actually works in early-stage developer ecosystems

DevRel looks different when developers are building on systems that are still changing underneath them.

Leading Developer Relations at Midnight has meant building an ecosystem from scratch, before launch, while the product is still taking shape underneath us.

It has been one of the most challenging and instructive experiences of my career. This is my first time leading DevRel pre-launch, with real users, real incentives, and real consequences when things break. When nothing is stable yet, every assumption about DevRel gets pressure-tested fast.

What actually helps developers move forward becomes very clear, very quickly.

As we get closer to taking the chain live, these patterns have become impossible to ignore.

Building before launch, with real developers and real consequences.

In early 2025, I wrote an article about DevRel at Midnight as a systems problem. Flywheels, journeys, scaffolding for scale. That thinking still holds.

What changed is that we stopped designing in the abstract and started operating those systems with real developers, real incentives, and real breakage. Some assumptions held. Others collapsed fast.

This post is not a replacement for that earlier strategy. It is what survived contact with reality.

For context, here’s the original piece: DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape.

1. Engagement programs are only valuable if they create directional movement

Healthy ecosystems help developers move somewhere, not just participate.

Quests, fellowships, Discords, events, and content have value only when they push developers forward, from curiosity to first build, from contribution to real ownership. Activity without progression is just motion, not momentum.

Early-stage programs must teach something concrete and lead to something tangible. Developers should leave knowing more than they did before and having built something they did not have yesterday.

If a program cannot answer “what does this unlock next?” it is not an engagement strategy. It is marketing noise with better branding.

2. Docs, tooling, and support are converging into a single developer experience

Developers experience your ecosystem as a single surface, no matter how many teams, orgs, or silos exist behind the scenes.

From their perspective, documentation, examples, local tooling, error messages, and support are inseparable parts of one experience. When something breaks, they do not diagnose which team owns it. They just decide whether to keep going.

The ecosystems that feel easy to build on are the ones that design these pieces as a coherent system, not as a collection of disconnected deliverables. Consistency, handoffs, and shared ownership matter more than perfect individual components.

If it feels smooth to the developer, it is because the org did the hard work to make it so.

3. Early-stage DevRel credibility is earned through consistency, not scale

Shipping reliably beats launching big, every time.

Weekly rhythms, predictable programs, clear expectations, and visible follow-through build trust faster than any splashy campaign ever could. It may not look glamorous from the outside, but developers notice when things run on time, work as described, and improve steadily.

Early-stage ecosystems are experiments by definition. The teams that earn trust are not the ones that avoid mistakes, but the ones that ship quickly, acknowledge what did not work, fix it, and keep moving. Momentum comes from iteration, not perfection.

Consistency plus learning beats polish every time.

**4. Early-stage DevRel succeeds or fails on unblocking, not inspiration**

The most effective DevRel teams are not necessarily the loudest but instead are the fastest at removing friction.

At early stages, developers do not churn because they lack motivation. They churn because they hit blockers, and no one clears them quickly enough. The teams that win treat DevRel as an unblocker responsibility first, and storytelling second.

5. Flat teams outperform rigid hierarchies in early ecosystems

When you’re building an ecosystem from zero, no one actually knows what will work yet. The fastest progress comes from teams that invite ideas from everywhere, try things quickly, and course-correct without ego.

We treat DevRel as a continuous experiment. Ideas come from the team, from builders, from the community. We test them. Some land. Many do not. We learn, adjust, and move forward. That is not chaos, it is disciplined adaptation under uncertainty.

Decentralized ecosystems demand this mindset. The community ultimately decides what sticks. The role of DevRel is not to dictate direction, but to create the conditions where good ideas surface, get tested, and scale when they earn it.

Everyone involved brings expertise. Everyone has seen DevRel done well and badly elsewhere. The teams that win are the ones confident enough to listen, humble enough to pivot, and disciplined enough to turn learning into action.

6. Small, well-instrumented communities outperform large, unmeasured ones

You do not need more developers. You need clearer visibility into the ones you already have.

Early-stage ecosystems win when teams can answer simple questions: who is progressing, who is stuck, and why. But insight alone is not enough. What matters is what you do next.

Strong communities turn feedback into action. They intervene when builders hit friction, create new paths when momentum stalls, and give developers clear reasons to keep building and deepening ownership.

Retention does not come from scale. It comes from attention. A smaller group with tight feedback loops, clear progression paths, and visible follow-through will always out-iterate a massive community where signals disappear into the void.

7. DevRel is becoming an operating system, not a job title

The most impactful DevRel work now lives in systems, not individuals.

What scales is not charisma or heroics, but workflows, standards, flywheels, tooling, and feedback loops that keep running week over week. Titles may change, but the work is increasingly about building durable engagement infrastructure.

Early-stage DevRel is less about growth hacks and more about earning trust under uncertainty.

Join the Midnight Conversation

We’d love for you to join this early ecosystem. Hear your feedback and ideas. Drop into Discord, open an issue, or fork a repo and show us what you’ve built.

An invitation to fellow DevRel builders

If you’re doing DevRel in a web3 ecosystem, especially an early one, I’d love to connect.

If you’re building DevRel while the platform is still taking shape, I’d love to compare notes.

What broke faster than you expected? What held up under real usage? What did you stop doing entirely?

--✨👩🏼‍💻 lolocoding

The Midnight Community Board: Building With the Community, Not Just For It

Lauren Lee — Fri, 01 Aug 2025 14:56:44 +0000

I believe a healthy ecosystem isn’t built for a community. It’s built with them.

That’s why the DevRel team at Midnight is thrilled to debut the Community Board, a new GitHub-based hub designed to make collaboration more transparent, inclusive, and efficient.

Just this week, a longtime partner and contributor shared feedback that struck a chord:

“The real frustration hasn’t been the number of channels. It’s not knowing what happens to our ideas or feedback once they’re shared. Without transparency into follow-up, it feels like issues just disappear.”

The Community Board is our solution to that exact problem. It gives developers, partners, and community members visibility into what’s happening with their feedback. And more importantly, a seat at the table to help shape priorities and the opportunity to pick up work themselves.

How the Community Board Works

Submission Flow

Anyone in the community can open an issue in the GitHub Community Hub repository.
Issues cover a range of categories:
- Content Development (blogs, videos, docs, etc.)
- dApp Development (example apps, new features)
- Feature Demo Ideas (including i18n/localization)
- Feature Requests and Suggestions
- Bug Tracking
- Midnight Improvement Proposals (MIPs)

Triage Process

An arbiter committee (currently DevRel, expanding over time to include dApp devs, SPOs, partners, and wallet holders) reviews submissions.
Submissions are given clear statuses: Needs Discussion, Triaged, Rejected.
Triage happens transparently, either live during Fireside Hangs or asynchronously on GitHub.

Grab-and-Go Board

Triaged issues move into the Grab-and-Go Board, a curated space for vetted ideas.
From here, contributors can claim work:
- DevRel team members
- Partners
- Ambassadors
- Ecosystem builders and developers

Community Voting

Issues on the Grab-and-Go Board can be upvoted with emoji reactions.
Voting provides constituency-driven signals, helping us prioritize based on real demand.

Execution and Integration

Picked-up issues flow through columns:

To Do → In Progress → Needs Review → Done.

Where needed, issues flagged for internal ownership move to the engineering teams' Jira board.
Over time, the Community Board could become a central part of the Midnight Improvement Proposal (MIP) process.

Automation

GitHub Actions automatically label issues, move them into the right boards, and reduce manual overhead, keeping the workflow fast and efficient.

Why this matters

Ends fragmentation: One place for all community ideas and feedback
Provides visibility: Everyone can see what stage a submission is in
Enables contribution: Community members can pick up vetted tasks directly
Democratizes prioritization: Voting ensures the roadmap reflects community demand
Broadens our builder base: Reduces pressure on core teams and grows a contributor ecosystem
Streamlines collaboration: Clear swimlanes, automation, and transparent triage keep the process efficient

This is still a work in progress, and we’ll continue refining it. But it’s a big step toward making Midnight a truly builder-driven ecosystem.

👉 Watch an overview/explainer video

👉 Explore the Community Board on GitHub

A huge thank you to Stevan Lohja and the DevRel team for building this, and to our community members for not just sharing feedback but leaning in to build alongside us. Together, we’re proving that privacy-first technology can be built in public, by and for the builders who believe in it. 🌱

Say Hello to example-counter and example-bboard

Lauren Lee — Tue, 15 Jul 2025 10:45:00 +0000

Midnight's Developer Relations team is actively shaping how developers learn, build, and experiment with privacy-first apps. In this post, we take a closer look at how DevRel is lowering the barrier to entry for new builders, supporting open-source tools, and helping the community navigate the unique challenges of developing on a privacy-preserving blockchain.

From ZIP Files to GitHub: Opening the Gates

Midnight is entering a new phase in our developer journey. Until now, developers had to download ZIP files from our documentation site just to get started. No versioning, no collaboration, no visibility.

That changes today.

The DevRel team is proud to share our first two open source example repositories: example-counter and example-bboard. These projects are more than demos. They’re intentionally scoped, composable references designed to help developers explore what’s possible with Midnight’s privacy-first architecture.

While our broader engineering team continues to open source core protocol components, these repos mark a different kind of milestone: showing others how to build on top of Midnight’s foundation. With versioned code and public visibility, developers can now fork, remix, and build with confidence.

A Simple Contract With a Purpose

example-counter is a minimal dApp that introduces the fundamentals of building on Midnight. It walks through the full development flow:

Writing a Compact smart contract
Running and compiling locally
Using public state
Deploying to the Midnight testnet
Sending transactions

pragma language_version >= 0.16;
import CompactStandardLibrary;

// public state
export ledger round: Counter;

// transition function changing public state
export circuit increment(): [] {
    round.increment(1);
}

It’s designed to build foundational literacy in Compact and Midnight’s dev tooling. It’s a simple but powerful way to learn Compact and become familiar with the development flow on Midnight.

Think of it as a “Hello, World” for privacy-enhancing dApp development.

Enforcing Rules Without Revealing Identity

example-bboard goes further. It simulates a public bulletin board, where users can post messages, and only the original author can remove their own post.

It’s a small app that teaches a big concept: Midnight enables identity-aware rules without revealing identity.

This repo covers how to:

Combine public and private state in a Compact contract
Use zero-knowledge proofs to enforce permissions
Validate ownership locally without exposing identity
Design UI flows that respect user privacy by default

It’s especially useful for teams exploring anonymous messaging, private voting, or access control without identity leakage.

What It Means to Build in the Open

Speaking personally, I’ve spent most of my DevRel career working in open source. But this is the first time I’ve been part of a company transitioning into it.

Open sourcing code isn’t just a technical milestone. It’s a culture shift. Releasing code publicly changes how a team thinks and operates.

It means moving from perfectionism to progress. From private Slack threads to public GitHub Issues. From “we’ll fix it internally” to “anyone can help improve it.”

It’s a commitment to building alongside others, not just for them.

These first example repos mark the beginning of that shift for Midnight. They’re designed to help others learn by doing and to demonstrate that privacy and collaboration can coexist.

Docs Are Up Next

We’re also preparing to open source our Midnight Docs repo.

This is a major step toward transparency, trust, and co-creation. We want the documentation to grow alongside the ecosystem, which means making it easier for contributors to suggest improvements, fix issues, and help shape the developer experience.

What’s Next?

This is just the start. In the coming months, the DevRel team will:

Publish more example dApps (and build them from scratch in the open)
Create reusable components and templates
Contribute improvements upstream to core tooling
Document real-world use cases for easier onboarding

We’re building in the open, for those who want to build with us.

Explore the Code

Join the Conversation

We’d love to hear your feedback, contributions, and ideas. Drop into Discord, open an issue, or fork a repo and show us what you’ve built.

Why We’re Shipping Curriculum Before It’s “Done” (And Why You Should Too)

Lauren Lee — Wed, 28 May 2025 11:14:43 +0000

At Midnight, we’re building a new kind of blockchain. One focused on data protection, developer experience, and real-world impact.

And as we grow our developer ecosystem, we’re doing something many teams are afraid to do.

We’re releasing our developer curriculum before it’s “done.”

Not because we’re lazy.

Because we believe that early feedback, real-world usage, and community collaboration will lead us to a stronger, more usable learning experience.

The Trap of Waiting for Perfect

Too many developer education teams hold back content until it’s “finished.” Polished. Market-ready.

But the truth is, good curriculum is never truly finished.

As someone who’s been both a high school English teacher and a DevRel leader, I’ve seen firsthand that the best learning doesn’t come from a perfect script. It comes from iteration. From shipping. From engaging with students/learners while the material is still taking shape.

So we’re taking a different approach.

We're shipping early and learning in the open. We're publishing usable content early, inviting feedback, and improving it alongside the developers who use it.

Introducing the Midnight Developer Academy

Recently, we quietly launched Midnight Developer Academy: our educational hub for developers who want to become experts in Zero-Knowledge Proofs and learn how to build DApps with data protection at the core.

Here’s what’s live now:

👩‍🎓 The first 3 of 8 core modules
✍️ Written, direct, and focused on hands-on learning
⚡ Designed for usability, not perfection

And here’s what’s on the roadmap/coming soon:

🎥 Video content and interactive labs
🌍 University partnerships and blockchain society integrations
💻 Self-paced learning on major online platforms
🧑‍🏫 Cohort-based workshops and live office hours
🤝 Partner-contributed modules on advanced use cases

This isn’t about checking a box. It’s about delivering real value now and letting our developers help shape what comes next.

Why I Love This Approach

By shipping early, we’re already seeing wins:

Developers are completing the first modules and asking for more
We’re collecting specific, actionable feedback to guide the next releases
Our community feels involved, not sidelined

This is our bet:

Progress beats perfection
Trust is built through transparency
Gatekeeping (is toxic and) slows learning

If you’re in DevRel, developer education, documentation, or product enablement, ask yourself:

👉 What’s the cost of waiting until it’s “done”?

👉 What opportunities are you missing while you polish?

👉 Could your community be helping you right now?

Build With, Not Just For

We believe that building with developers, not just for them, is how ecosystems thrive.

That means opening the door earlier. Listening harder. And iterating out in the open.

So here’s our call to action to the Midnight community:

💥 Dive into the first three modules

📝 Tell us what’s missing

📣 Help shape what comes next

We’re not waiting for perfect.

We’re learning, shipping, and growing together!

DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape

Lauren Lee — Wed, 23 Apr 2025 09:09:15 +0000

“Don’t optimize for today. Build the scaffolding for scale.”

Intro

The pace of web3 is dizzying. Protocols evolve weekly. Docs lag behind releases. Tooling is in flux. Community sentiment shifts with the market. For Developer Relations teams, that means operating in a state of constant motion and navigating uncertainty while trying to create structure and momentum.

On our DevRel team at Midnight, we’re not just reacting, we're designing systems that can outlast us. This blog post is a look inside how we're thinking about DevRel in an emerging ecosystem, and what it takes to build not just community, but infrastructure for community.

From tasks to systems: The DevRel Flywheel

The traditional DevRel playbook doesn’t hold up when the ground keeps shifting. That’s why I’ve shifted from thinking in terms of tasks, such as “write this guide” and “host that hackathon,” to thinking in terms of systems.

Enter the DevRel Flywheel. A concept originated by Matthew Revell that we’ve adapted for web3. Here’s how it works at Midnight:

Developer activity sparks early traction and interest
Community engagement amplifies that momentum
Trust and support build confidence and
Ecosystem visibility brings new builders and use cases
New projects fuel more developer activity

The more we feed the flywheel with education, support, and visibility, the less we need to push manually. Our role becomes about momentum maintenance, not manual motion.

Mapping the developer journey at Midnight

To make the flywheel spin faster, we have mapped the journey a developer typically takes within our ecosystem. This helps us design the right interventions at each stage, and it aligns with Phil Leggetter's AAARRRP framework (Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product) used across DevRel and growth teams.

Stage	Midnight Journey	AAARRRP Phase
First Touch	Social, talks, blogs, conferences	Awareness + Acquisition
Education	Tutorials, Discord livestreams, ZK workshops	Activation
Documentation	Quickstarts, use-case driven docs, APIs + SDKs	Retention
Hackathon	Build events, project feedback, prizes	Retention + Referral
Ecosystem Contributor	PRs, mentoring, writing, core feedback	Referral + Product Growth

This journey acts as both a map and a compass. It gives us clarity on:

Where we’re losing developers
Where we can accelerate outcomes
How to tailor support, education, and incentives at each stage

We don’t just hope developers stick around. We design the journey so they thrive at every stage.

What we’re learning (and unlearning)

We’re early in this journey, and we’re experimenting constantly. Here are a few unexpected lessons from our DevRel systems design so far:

Education should drive contribution, not just consumption
Docs should meet developers by intent, not by section
Example apps should collect feedback, not just showcase use
Support should default to public and persistent, not private DMs
Incentives should build reputation, not just distribute prizes

Not everything from web2 works in web3. And sometimes, what didn’t work there is what works here.

Rethinking hackathons in web3

I used to be skeptical of hackathons. I worried they were just prize-driven traffic spikes with no long-tail return. But at Midnight? They’re proving to be launchpads.

We’re seeing multiple hackathon teams/projects go on to receive grants, and we’re now actively investing in the winners' journeys. This doesn’t mean we won’t keep evolving the format (we will), but it’s changed how I think about incentives, retention, and early-stage builder support across the board.

A system that feeds itself

What we’re building now will shape the culture and sustainability of our developer community for years to come. If we only optimize for today (fix this doc, answer that question), we’ll burn out before we ever get to scale.

So instead, we’re asking:

How can we structure support so that our community helps itself?
How can we collect feedback so that every new tutorial gets smarter?
How can we build with devs, not just for them?

An invitation to fellow web3 DevRel builders

If you’re doing DevRel in a web3 ecosystem, especially an early one, I’d love to connect.

What’s working for you? What isn’t? What does your flywheel look like?

Let’s swap notes. Let’s compare scars. Let’s collaboratively build systems that make it easier for the next wave of builders to build what matters!

-- ✨👩🏼‍💻 lolocoding

We Belong in Web3

Lauren Lee — Wed, 08 Mar 2023 18:14:21 +0000

There's no denying that representation in the tech industry is pretty terrible. I've been the only woman on countless engineering teams, and it frankly sucks.

Not only does it suck, but the world has seen time after time how a lack of diversity has negatively impacted systems and designs. (Such as when Google's image recognition services made offensive classifications of minorities, Microsoft's chatbots adopted hate speech, and Amazon technology failed to recognize users with darker skin colors.)

Initiatives like Girls Who Code and Ada Developers Academy are working to change this and are dedicated to making tech more representative of society at large. But, it's an ongoing battle, as women still only hold 1/4 of tech-related jobs.

When it came to Web3/crypto,

I always viewed it as just another boys club, a toxic niche - with limited utility - within the already adversarial wider tech space. Just another subset of tech where I didn't feel represented or welcome. When I heard about the Bitcoin conference renting out a strip club for a networking party a few years back, I rolled my eyes and decided it was just another area of tech probably not worth investing my time.

That all changed for me the day I stumbled upon a video of Gavin Wood, the founder of Polkadot and Ethereum, speaking about his vision of creating a better internet and society - one where technology is used to forge new ways to collaborate, organize, and trust one another.

"Web3 is really about allowing people to come together and coordinate their efforts for something greater than the sum of its parts."

And that really resonated with me. I soon learned about Polkadot's green approach to uniting blockchains forming the basis for a truly interoperable decentralized web. It genuinely has the capability to transform technology and society itself, and I knew I wanted to be involved.

Yes, the same problems exist with representation/toxicity in Web3 as there are in tech in general. But we have to remember it is still early days when it comes to Web3 and blockchain tech.

It's still possible to improve the community before it reaches a tipping point.

Women and gender minorities can get involved now and help steer the direction. We are now, but we don't have to be minorities within the space.

And think of how powerful that could be if we get involved while things are still shaping!

Sure, some bros have made some mistakes while at the helm so far, but why not jump in and course correct while we still can?

It's not too late. It's still possible to help Web3 not repeat the mistakes of the wider tech industry.

So that's what I'm doing. That's why I'm now here in the Web3 space. I'm beyond inspired by Polkadot's mission and feel equally excited about being a part of it all.

Yes, I want to be a part of building the decentralized web, but more importantly, I want other women to join me.

I want to create space for them to feel welcome, included, and a part of that journey.

Let's close the gender gap in Web3.

The new season of my podcast, We Belong Here, has recently launched - and it's completely dedicated to celebrating the stories of those who are diversifying the Web3 space!

🎙Check out to We Belong Here today🎙

I've always hated when people gatekeep and make tech seem cool by claiming how difficult it is to learn. There's, without a doubt, an opportunity to humanize Web3 and blockchain technology and make it more approachable.

As a prior high school teacher, I know how important it is to break down complex topics and make them engaging and accessible to all styles of learners.

I'm excited to share my learning journey with anyone curious about Web3 but have never felt welcomed or encouraged to learn more.

I want to unlock the complexities.

Share my discoveries.

Invite newbies to ask questions.

Share resources.

Build community.

Learn together!

So join me. I promise to remove my ego, to be vulnerable, and to share my learnings with you - to document my confusion and my dumb questions - so you don't feel alone if you're confused too.

No Crypto Bros here, just me, a new mom who's stoked to build decentralized applications and who will teach you how to too.

-- 👩🏼‍💻Lauren (lolocoding.com)

Nevertheless, Lauren Focused on Community✨

Lauren Lee — Thu, 04 Mar 2021 13:34:53 +0000

Hi! My name is Lauren 👩🏼‍💻, I sometimes go by @LoLoCoding, my pronouns are she/her, and I'm so excited to know you.

I realized today that I started my podcast, We Belong Here: Lessons from Unconventional Paths to Tech exactly two years ago!

As a bootcamp grad and career changer myself, I remember craving community and wanting to know that I was not alone in my journey to tech.

I was curious to learn how other people framed their untraditional routes to tech as an asset to recruiters, their future employers, and colleagues.

What transferable skills did the ballerina/barista/lawyer/scientist/teacher turned coder bring to the table and how did they differentiate themselves from CS grads?

My curiosity led to me asking a similar set of questions to my bootcamp classmates about their experiences in the industry. Slowly, I expanded beyond that network and began to record those conversations.

These are the questions I asked my guests:

Can you tell me more about the experiences you had before you entered the tech industry? Take me back in time and tell me what you studied in school or your early life passions.
How did you decide to learn to code and how exactly did you learn it?
What kept you from entering the tech industry before you did?
How has your past as an xyz helped you today in your role as a developer?
Or rather, do you ever find yourself using the skills you learned from those experiences today?
How do you spin your past and present it as an asset?
Can you tell me about a time you felt like an outsider and how you have dealt with that feeling?
Can you share any life lessons you’ve learned from your transition to tech?
Do you have any advice for those wanting to transition into tech that you can share?

All in an effort to create a community for career changers and those diversifying the tech industry.

So, in celebration of International Women’s Day, the two-year anniversary of the #WeBelongHere podcast, and the #SheCoded movement, I thought I’d look back and share the lessons I’ve learned from those conversations and this incredible community:

There is so much to learn in tech that it is easy to become overwhelmed by it all. Try to learn one thing a day. Even if it’s incredibly small.

Be kind and give yourself the freedom to take days off from that learning goal though.

Keep a journal/log of what you’re learning.

When you’re battling with a particularly tough bug in your code and/or facing feelings of imposter syndrome and self-doubt, you’ll have a tangible reminder of all the things you’ve achieved along the way.

Speaking of imposter syndrome, let me just say this now, we ALL face it.

You’ll hear tons of people giving advice on how to combat, avoid, or overcome it. But frankly, I’ve learned to just own it. As in, to embrace it. To name it and move on throughout my day.

When those familiar feelings inevitably creep up and whisper the reminders that, I don’t belong or I’m not smart enough, I’ve decided to simply acknowledge the emotion, welcome her to the party, and get to work. I don’t let it overpower me - instead I allow myself to hold two truths at the same time:

I may be nervous or intimidated
But I am also capable and prepared

Speaking of feeling nervous or out of my comfort zone, I’ve learned to stop hiding from them and that there is joy to found when sharing those emotions with others.

In 2020, I dove headfirst into Twitch and live streaming. I started a series called, Lauren Learns Things where I quite literally, tried to learn new things live each episode.

A bunch of STRANGERS watching me debug or try to understand a new language?? Talk about a vulnerable-making experience.

At first, it felt terrifying.

I was going to admit that I hadn’t ever written in PHP to everyone and try to build something alongside an expert? What was I thinking? Everyone would discover that I don’t know anything!

But instead. I discovered the power of celebrating what I don’t know. How incredibly fun it can be to say, "Yeah I don’t know what’s going on right now in the code, but let’s figure it out together! That sounds fun, doesn't it?!"

I learned how relationships can grow from that sort of honesty.

When we model and share our vulnerabilities, authentic relationships can flourish from that honesty.

I’ve learned to stop struggling alone. And that community is, frankly, everything.

If you’re learning to code, it’s more enjoyable to do it collaboratively! Twitter can be great for that, but there are also a ton of online meetup groups such as Women Who Code that offer a sense of togetherness.

I’ve decided to only surround myself with people who embrace my authentic self and remind myself daily that the journey of learning is a part of the fun.

I’ve learned to speak up when confused. And to not suffer silently.

I’ve embraced being a forever-student

Sure, it is ego-boosting and sometimes fun to be an expert, but it’s more rewarding to always be challenging myself to learn new things.

It’s easy to get overwhelmed by all the things you don’t know, but if you spin it to see it all as just new and exciting opportunities to learn, I think it becomes less daunting.

I’ve learned that growth comes from being uncomfortable. From pushing ourselves and our community to step outside of our safe spaces and learning from one another and from our mistakes.

There is room for all of us at the top. Collaboration over competition. Let’s lift one another up and create space and opportunity for each other.

Ultimately, I’m so grateful for the podcast and the community we’ve created as it has grown into a space where we can connect, share resources, mentor, be vulnerable, know that we're never alone, and build community.

Be sure to subscribe wherever you find your podcasts to never miss a future episode✨

And come join the We Belong Here Discord and be a part of the community!

Thanks for reading! And for being my internet friend 💖 Happy #IWD2021 everyone 😊

📬If you want to be a guest on the pod, or know a career changer I should interview, be sure to NOMINATE them!

--
✨ Lauren Lee
@LoLoCoding

A Retrospective for Men in Tech

Lauren Lee — Thu, 05 Mar 2020 13:11:05 +0000

Happy International Women’s Day, everyone! Heck YES, a day to celebrate being a woman in tech!

In honor of the holiday's spirit, there’s bound to be countless articles, videos, and Instagram captions about the #shecoded movement, on the topic of female empowerment, and what it in general means to be a #girlboss in tech in 2020.

And while I’m obviously all for that content, I thought I’d author something for those who may be feeling a little left out today: the men! (I kid, I kid, every other day is your day when you’re a man in tech!)

Having existed in both a female-dominated industry as a high school English teacher for nearly a decade and now having spent the past few years in the exact opposite space as a software engineer and a woman in tech, I figured it’s about time to hold my very own retrospective on gender in tech.

Allow me to briefly woman-splain a retrospective for you, dear reader: retros are meetings held by software development teams at the end of either a sprint or project. They’re an opportunity for the team to evaluate its past working cycle and make actionable plans for improvements to be made in the future.

Thus I thought it’d be fun to reflect on the lessons and opportunities for improvement addressed to the majority of my fellow coders, colleagues, and peers in tech. Yes, that means you, gentlemen!

Retrospective for Men in Tech:

Caveat: In this piece, I’m speaking for myself and not for women in general. These are my personal observations & it’s important to recognize my privilege as a cis white woman living in the US.

Start

Note: I know some of you are already doing some of these things. Thank you, and please, keep it up! Just shift these points to your own Continue column.

Believing women.
Calling out other men’s bullshit, even when it makes you uncomfortable. Actually, especially if it does.
If a woman is in a tech space, assume that they’re technical, don’t assume they’re someone’s +1
Believing that I belong here even if my interests don’t include video games.
Looking for women at your company. In your org. On your team. If you don’t see them represented in one of those spaces, speak up, and ask why.
Developing an awareness of intersectionality. And understanding that intersectional feminism is a thing. If you don’t yet, learn about it. We are more than just our identity as a woman.
Perceiving this sort of work as self-development and critical work.
Identifying and finding other men that are doing this crucial work well and learn from them.
When hunting for a new role, ask for stats on the team/company’s diversity and inclusion during your interviews.

Stop

Thinking it's a compliment when you say, “You don't look like a software developer!”
Asking the one woman on your team to be the voice of all women. I do not speak on behalf of us all.
Assuming tech is a system of meritocracy and that if there aren’t women on your team that it’s because they didn’t earn a spot on the team.
Putting the responsibility on us to fix your sexism.
Assuming I’ll do the front end when collaborating on a project (and associating front end with femininity).
Expecting me to educate you on how to make the other woman on our team feel welcome.
Making a joke in the lunchroom that I am the diversity hire on the engineering team.
Assuming women in the office will organize birthday cards and presents.
Taking up the talk space in meetings. And repeating what I said and framing it as your own idea.
Using the word “female” or infantilizing terms for your coworkers like “girls”.

Continue

Being an ally.
Calling your coworker out when they use gendered language.
Speaking up for me when I don’t have a seat at the table.

Alright, I'll acknowledge that this list may feel like a LOT of information to process! But, I hate to break this to you, but this is quite literally JUST the beginning. There's so much more that could be said and complex nuances to be acknowledged. But I think for the sake of setting tangible goals and chunking learning opportunities into consumable action items, that’s all I’ll say today. I hope that there are at least a few pieces of actionable changes that you can put into place after reading this retro.

Again, it is not a woman’s responsibility to educate men. So I don’t feel the need to hold your hand through this journey with you. It’s on you. But genuinely, thank you for taking the time to read this and embark on an important path to equality.

And if you're up for it and not too ridiculously triggered after reading this piece, please feel free to reach out at @lolocoding. Be sure to share actions you take to be a #shecodedally and let's engage in some healthy dialogue and highlight the folks who are doing this sort of work every. single. damn. day.

How to Build a Dashboard of Live Conversations with Flask, React, and Nexmo

Lauren Lee — Wed, 25 Sep 2019 15:58:22 +0000

Nexmo recently introduced the Conversation API. This API enables you to have different styles of communication (voice, messaging, and video) and connect them all to each other.

It's now possible for multiple conversations within an app to coincide and to retain context across all of those channels! Being able to record and work with the history of a conversation is incredibly valuable for businesses and customers alike so, as you can imagine, we're really excited about this.

Find out more of what can be done with programmable conversations at Vonage Campus, our first customer and developer conference taking place in San Francisco on October 29-30. It's free to attend, so request your invite now!

What The Dashboard Does

This tutorial covers how to build a dashboard with Flask and React that monitors all current conversations within an application. The goal is to showcase relevant data from the live conversations that are currently happening in real-time.

When a single conversation is selected from the list of current conversations, the connected members and events will be displayed. An individual member can then be selected to reveal even more information related to that particular user.

What Does The Conversation API Do?

The Nexmo Conversation API enables you to build conversation features where communication can take place across multiple mediums including IP Messaging, PSTN Voice, SMS, and WebRTC Audio and Video. The context of the conversations is maintained through each communication event taking place within a conversation, no matter the medium.

Think of a conversation as a container of communications exchanged between two or more Users. There could be a single interaction or the entire history of all interactions between them.

The API also allows you to create Events and Legs to enable text, voice, and video communications between two Users and store them in Conversations.

Workflow of The Application

Create A Nexmo Application

To work through this tutorial, you will need a Nexmo account. You can sign up now for free if you don’t already have an account.

This tutorial also assumes that you will be running Ngrok to run your webhook server locally.

If you are not familiar with Ngrok, please refer to our Ngrok tutorial before proceeding.

First, you will need to create a Nexmo Application:

nexmo app:create "Conversation App" http://demo.ngrok.io:3000/webhooks/answer http://demo.ngrok.io:3000/webhooks/event --keyfile private.key

Next, assuming you have already rented a Nexmo Number (NEXMO_NUMBER), you can link your Nexmo Number with your application via the command line:

nexmo link:app NEXMO_NUMBER APP_ID

Clone Git Repo

To get this app up and running on your local machine, start by cloning this repository:

git clone https://github.com/nexmo-community/nexmo-python-capi

Then install the dependencies:

npm install

Copy the example .env.example file with the following command:

cp .env.example > .env

Open that new .env file and fill in the Application ID and path to your private.key that we just generated when creating our Nexmo Application.

Flask Backend

The important doc to inspect within our Flask files is the server.py one as it establishes all of the different endpoints the Conversation API.

The function, make_capi_request() connects to Nexmo and authenticates the application:

def make_capi_request(api_uri):
   nexmo_client = nexmo.Client(
       application_id=os.getenv("APPLICATION_ID"), private_key=os.getenv("PRIVATE_KEY")
   )
   try:
       response = nexmo_client._jwt_signed_get(request_uri=api_uri)
   except nexmo.errors.ClientError:
       response = {}

   return jsonify(response)

Underneath that, we create the necessary routes:

@app.route("/")
def index():  # Index page structure
   return render_template("index.html")

@app.route("/conversations")
def conversations():  # List of conversations
   return make_capi_request(api_uri="/beta/conversations")


@app.route("/conversation")
def conversation():# Conversation detail
   cid = request.args.get("cid")
   return make_capi_request(api_uri=f"/beta/conversations/{cid}")

@app.route("/user")
def user():  # User detail
   uid = request.args.get("uid")
   return make_capi_request(api_uri=f"/beta/users/{uid}")

@app.route("/events")
def events(): # Event detail
   cid = request.args.get("cid")
   return make_capi_request(api_uri=f"/beta/conversations/{cid}/events")

Once authenticated, each of these routes accesses the Conversation API based on the Application ID and eventually the Conversation or User ID.

React Frontend

We’ll make use of React's ability to break our code into modularized and reusable components. The components we’ll need are:

At the App.js level, notice that the "/conversations" endpoint is called within the constructor. Meaning that if there are any current conversations within the application, they are immediately displayed onto the page.

fetch("/conversations").then(response =>
  response.json().then(
    data => {
      this.setState({ conversations: data._embedded.conversations });
    },
    err => console.log(err)
  )
);

The user then will have the option to select one of the conversations from the list and the meta details of that conversation, such as name and timestamp, will be displayed.

<div>
  <article className="message is-info">
    <div className="message-header">
      <p>{this.props.conversation.uuid}</p>
    </div>
    <div className="message-body">
      <ul>
        <li>Name: {this.props.conversation.name}</li>
        <li>ttl: {this.props.conversation.properties.ttl}</li>
        <li>Timestamp: {this.props.conversation.timestamp.created}</li>
      </ul>
    </div>
  </article>
  <Tabs
    members={this.props.conversation.members}
    events={this.props.events}
    conversation={this.props.conversation}
  />
</div>

Notice that once a particular conversation has been selected two tabs become visible: Events and Members.

Members is set as the default state, meaning that is displayed first. It is at this point that the "/conversation" and "/events" endpoints are called. Using the cid that is passed within the state, the details of the current members and events are now available.

refreshMembers = () => {
  fetch("/conversation?cid=" + this.props.conversation.uuid)
    .then(results => results.json())
    .then(data => {
      this.setState({ members: data.members });
    });
};

refreshEvents = () => {
  fetch("/events?cid=" + this.props.conversation.uuid)
    .then(results => results.json())
    .then(data => {
      this.setState({ events: data });
    });
};

The MembersList.js component will call the /user endpoint to retrieve even more data on that particular user, which then is shown within the MemberDetail.js component.

showMemberDetails = user_id => {
  fetch("/user?uid=" + user_id)
    .then(results => results.json())
    .then(data => {
      this.setState({ member: data });
    });
};

Connect It All Together

To start up the backend, run the Flask command:

export FLASK_APP=server.py && flask run

And in another tab within your terminal, run the React command:

cd frontend-react && npm start

Open up http://localhost:3000 in a browser, and your app will be up and running!

Any conversations that are currently running within that connected application will now be visible within this dashboard.

Congrats! You've now created an application with Flask, React, and Nexmo's Conversation API. You now can now monitor all sorts of things related to your application's conversations. We encourage you to continue playing with and exploring this API's capabilities.

Contributions And Next Steps

At Nexmo, the Conversation API is currently in beta and is ever-evolving based on your input and feedback. As always, we are happy to help with any questions in our community slack or support@nexmo.com.

The post How to Build a Dashboard of Live Conversations with Flask and React appeared first on Nexmo Developer Blog.

Forem: Lauren Lee

Midnight network is live

Scaling real-world use with fourth-generation blockchain

Unlocking Real-world privacy

Sustainable costs and predictability

Aligning incentives with dual-component tokenomics

NIGHT for utility and governance

DUST is the renewable network resource

Abstracting away complexity with Compact programming language

Launching alongside leading institutions

Multiphase roll-out strategy for stability and security

Progressive decentralization

What to do next…

Get your project on the map

Why this matters

The attribution process

Compounding developer results

Step 1: Add GitHub topics

Step 2: Add one attribution sentence to your README

Step 3: Open a PR to the Awesome dApps list

Earn Zealy points while you're at it!

Three steps, once per repo, permanent record

Aliit Fellowship Now Accepting Cohort 2 Applications

About the Aliit

The Candidacy Structure

How Contribution Works: The Four Personas

Benefits of Fellowship

How Admissions Work

How to apply

DevRel When the Ecosystem Is Still Taking Shape

DevRel looks different when developers are building on systems that are still changing underneath them.

1. Engagement programs are only valuable if they create directional movement

2. Docs, tooling, and support are converging into a single developer experience

3. Early-stage DevRel credibility is earned through consistency, not scale

4. Early-stage DevRel succeeds or fails on unblocking, not inspiration

5. Flat teams outperform rigid hierarchies in early ecosystems

6. Small, well-instrumented communities outperform large, unmeasured ones

7. DevRel is becoming an operating system, not a job title

Early-stage DevRel is less about growth hacks and more about earning trust under uncertainty.

Join the Midnight Conversation

An invitation to fellow DevRel builders

--✨👩🏼‍💻 lolocoding

The Midnight Community Board: Building *With* the Community, Not Just For It

How the Community Board Works

Why this matters

Say Hello to example-counter and example-bboard

From ZIP Files to GitHub: Opening the Gates

A Simple Contract With a Purpose

Enforcing Rules Without Revealing Identity

What It Means to Build in the Open

Docs Are Up Next

What’s Next?

Explore the Code

Join the Conversation

Why We’re Shipping Curriculum Before It’s “Done” (And Why You Should Too)

The Trap of Waiting for Perfect

Introducing the Midnight Developer Academy

Why I Love This Approach

Build With, Not Just For

DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape

Intro

From tasks to systems: The DevRel Flywheel

Mapping the developer journey at Midnight

What we’re learning (and unlearning)

Rethinking hackathons in web3

A system that feeds itself

An invitation to fellow web3 DevRel builders

We Belong in Web3

When it came to Web3/crypto,

It's still possible to improve the community before it reaches a tipping point.

It's not too late. It's still possible to help Web3 not repeat the mistakes of the wider tech industry.

Let's close the gender gap in Web3.

🎙Check out to We Belong Here today🎙

I want to unlock the complexities.

Share my discoveries.

Invite newbies to ask questions.

Share resources.

Build community.

Learn together!

Nevertheless, Lauren Focused on Community✨

**4. Early-stage DevRel succeeds or fails on unblocking, not inspiration**

The Midnight Community Board: Building With the Community, Not Just For It