gnolang / hackerspace Goto Github PK

Tinker, build, explore Gno - without the monorepo!

Python 100.00%

hackerspace's Introduction

Hackerspace

Disclaimer: This repository is an experimental playground for creative ideas, projects, and collaborations. Nothing here is guaranteed to become an official point. For official matters, refer to the main repo at https://github.com/gnolang/gno.

Welcome to the Hackerspace repository! This is a dedicated place for tinkerers, builders, and experimenters to freely explore ideas, track projects, and pursue individual and collaborative initiatives with fewer constraints compared to the main repository.

Goal

The primary objective of this repository is to provide a creative and open environment for innovation and exploration. By having this dedicated space, we aim to:

Foster a spirit of experimentation: Encourage out-of-the-box thinking, unconventional approaches, and bold ideas.
Facilitate collaboration: Enable individuals and teams to collaborate on projects, share knowledge, and learn from each other.
Track personal initiatives: Keep a record of personal projects, prototypes, and experiments, allowing individuals to showcase their creativity and progress.
Maintain focus on the main repository: Keep the main repository clean and focused on the established roadmap and core development efforts.

We encourage you to keep the Hackerspace repository organized and structured. Feel free to propose an organization that makes sense for your projects. You can consider organizing by your name or by the category or theme of the experiment. This will help create a cohesive and navigable space for all contributors.

Remember, the Hackerspace is all about pushing boundaries, exploring new territories, and embracing the spirit of curiosity and innovation.

Let's build amazing things together and make the most of this creative space while keeping the main repository focused on the roadmap and core objectives.

Happy hacking!

hackerspace's People

Contributors

Stargazers

Watchers

Forkers

schollz michaelfrazzy omahs iam-agf

hackerspace's Issues

Flippando Builder Journey

Hey Dragos,

Welcome to the Gno.land Grant Program, I've started an issue for you to share updates on Flippando and introduce yourself to the team and community.

META: Onbloc Content (GnoDesk, Blogs, etc)

Co-content creators: @adr-sk @peteryoon with assistance from @dongwon8247 and technical members of Onbloc.
Special thanks to the @gnolang/ops @gnolang/core-contributors for conducting thorough reviews of our content.

This issue is a comprehensive list of content produced by Onbloc on our blog channels (Onbloc, Gnoswap and Adena). What you can expect from this issue is regular content such as ecosystem & product updates and spontaneous content such as research blogs, event recaps, and educational materials. The key objectives that we aim to accomplish through this initiative are:

Raise awareness and educate the public about the Gno.land project.
Aggregate information scattered across various channels of Gno.land and share them with the community.
Introduce Onbloc's initiatives and products.

GnoDesk

A weekly Gnoland ecosystem update. The purpose of this series is to aggregate information scattered across various channels for everyone.

Blogs

Our publications featuring initiatives on Gno.land, such as research findings, event summaries, and product updates.

Research

Events

Updates

2023 Q1 Onbloc Quarterly Update

Gnoswap

Adena

Patch Notes

️v1.2.2 | ️v1.3.2 | v1.4.0 | v1.4.2 | v1.5.0 | v1.6.0 | v1.7.0 | v1.8.0 | v1.9.0

Developer Portal

In-depth documentation for Gnoland developers, providing introductions, extensive tutorials, and development resources.

(To be merged with the Official Gno Docs - http://docs.gno.land/)

GitBook: https://docs.onbloc.xyz/
GitHub: https://github.com/onbloc/gnoland-tutorials

Gnolang 101

An introductory course for Gno beginners.

GitHub: https://github.com/onbloc/gnolang-101

Publish (all?) our conversations

META: GnoSwap

Overview

Gnoswap is the first Concentrated Liquidity AMM DEX developed with Gnolang, inspired by Uniswap V3—the most advanced and battle-tested AMM. Its goal is to bring censorship-resistant, non-custodial, and secure financial infrastructure to Gnoland, establishing itself as the most capital-efficient liquidity layer within the Gnoland ecosystem.

Gnoswap is entirely permissionless, allowing any GRC20 token realms to be added and traded as soon as they're deployed to the GnoVM, without requiring any registry approval from the platform.

URLs

Beta: https://beta.gnoswap.io/
Realms (contract): https://github.com/gnoswap-labs/gnoswap
Interface: https://github.com/gnoswap-labs/gnoswap-interface
Docs: https://docs.gnoswap.io/
Blog: https://medium.com/@gnoswaplabs
Twitter: https://twitter.com/gnoswaplabs

Key Features

Swap: Supporting swaps for any token on Gnoland including GRC20s, native tokens, and IBC-transferred tokens. The SwapRouter ensures that every swap receives the best possible pricing.
Create Liquidity Positions: Abstracting the complexities involved in Concentrated Liquidity to provide a simple, intuitive experience for liquidity providers while offering full customizability.
Stake Position: Offering the Warm-up Period, a novel staking mechanism designed to incentivize long-term liquidity provision while offering flexibility for those who frequently need to adjust their price range to stay active due to liquidity concentration.
Incentivize Pool: Providing a tool that incentives extra rewards, which can be added to bootstrap liquidity in pools.
Wallet: Viewing all of your assets at a glance with real-time updates on liquidity provision and staking. Support for IBC transfers will be available in the future.
Dashboard: Analyzing platform metrics and on-chain activities within Gnoswap.
(Upcoming) Governance: Providing governance tools for xGNS holders who make key decisions for the platform.
(Upcoming) Launchpad: Offering a tool to facilitate the launch of crypto projects within the Gnoland ecosystem.
(Upcoming) Perpetual Trading: Offering perpetual trading leverage.

Milestones

Gnoswap Closed Beta Launch //Q4 2023
Gnoswap Open Beta Launch //Q1 2024
Gnoswap Mainnet Launch //Q2 2024
Launchpad Platform Launch //Q3 2024
Multi-chain Support Enabled //Q4 2024
Customizable Perpetual DEX Launch //H1 2025

Support

Support needed from the core team / Gno community to make Gnoswap better!

December 2023

Contribution to Gnoswap Contract (especially security side), if you're interested in AMMs: https://github.com/gnoswap-labs/gnoswap
Contribution to Gnoswap Interface, if you're interested in improving the Web3 UI/UX: https://github.com/gnoswap-labs/gnoswap-interface
Gno Core (while we're working on Gnoswap, we're actively contributing to Gno Core with our findings of essential features)
- bigint for arbitrary precision: gnolang/gno#764
  - For this, we're working on uint256 alternatively as Manfred suggested.
- json without reflection for front-end: gnolang/gno#1415
  - For this, we're implementing it without reflection.
- emit and event subscription function from Gno Core: gnolang/gno#575
  - For this, we're working with Milos.
- GasFee (estimateGas) implementation in Gno:
  - For this, nothing is being done from our side.

Gnowiki (dApp)

Introducing Gnowiki: a Wikipedia alternative that offers a cutting-edge approach to knowledge sharing and collaboration.

Key Features:

Reputation Score:, serving as an incentive for contributors and users to engage actively in building and curating content (gnolang/gno#872).
Moderation Without Censorship:, fostering open discussions and diverse viewpoints while ensuring responsible moderation without resorting to censorship (#7).
Verifiable Information: Carmel provides tools for fact-checking, promoting healthy debates, and incentivizing investigations to maintain a high standard of accuracy and reliability. (https://github.com/allinbits/carmel)
Graph-based Knowledge Organization: Lighthouse empowers users to explore knowledge through intuitive and interconnected graphs, enabling a more holistic understanding of subjects. (allinbits/carmel#5)

Berty's GnoMobile / Gno Native Kit Builder Journey

This documents the journey of Berty into Gno.land.

The two objectives of the first month of our Builder project are:

Create a Proof of Concept of an existing Gno example app running on a mobile phone. This will prove that we can run Gno on a mobile (or identify issues that need further work). The PoC code will go into https://github.com/gnolang/gnomobile .
Based on this experience to produce a detailed technical plan for further work to create a framework where developers can bring their Gno apps to mobile.

In this Journey, we will introduce our team, document our experience using Gno, track our issues and solutions, and keep meeting notes.

Idea: p/demo/evm

Introducing a Gno-based EVM (Ethereum Virtual Machine) that serves as an intriguing proof of concept rather than a production-ready solution. It initially focuses on providing comprehensive logic support while future enhancements aim to bridge "syscalls." This capability allows for writing Solidity contracts that can be interpreted by Gno, unlocking new possibilities for bytecode execution.

It's worth mentioning that this project holds the potential to offer a novel approach for verifying successful contract porting and exploring other potential use cases.

Related with gnolang/gno#885 (p/demo/bf).

Add an interactive debugger in gnoVM

Provide gnoVM with an interactive symbolic debugger similar to delve, except that the debugger facility is integrated in the gno executable.

Varmeta's Builder Journey

Welcome to Varmeta's Builder Journey!

This issue serves as a comprehensive introduction to Varmeta and a place where you can expect regular updates from us. We hope you'll find it very helpful to read this issue to learn more about Varmeta, and we look forward to collaborating with you! Let's embark on this journey together!

Introduction:

Varmeta was founded in 2020 with a focus on blockchain and virtual reality/augmented reality technologies. Starting with only three members, we now have 40 engineers who are highly skilled tech experts, driven by determination, enthusiasm, and commitment to providing cutting-edge technology services.

We aim to contribute to the ecosystem of emerging blockchains, addressing lingering issues in traditional ones. We believe that the design philosophy for Gnoland developers has the potential to make it one of the most widely adopted smart contract platforms globally, and we are committed to supporting this initiative by providing various applications for its ecosystem.

Varmeta Links:
Website: https://www.var-meta.com/
LinkedIn: https://www.linkedin.com/company/var-meta/

Products:

I will provide you with brief explanations of our products with relevant links here.

FanChain:

FanChain is a platform that enables streamers and influencers to create and issue NFT collections, including generative and membership NFTs. Fans can purchase these NFTs on our marketplace and participate in exclusive community events on Discord and Telegram. Additionally, FanChain offers a crypto-based donation system for viewers to support their favorite creators.

NFT Creation: Streamers and influencers can create and issue NFT collections, including generative and membership NFTs.
Marketplace: Users can buy, sell, and trade NFTs on our platform, fostering a vibrant and active community around content creators and their fans.
Community Management: FanChain will offer tools for streamers and influencers to manage their Discord and Telegram communities, ensuring that only NFT holders can access exclusive channels and events.
Crypto Donations: Viewers can support their favorite creators by donating cryptocurrency, with donation information displayed during live streams.

Technology Stack: FanChain will be built using a combination of React and Node.js for the frontend and backend.

Website: https://www.fanchain.network/
GitHub: (Currently private, will be made public in 2024)

Please follow this to check all the update from our progress.

Golang working group / Gnolang 1.x

Here are some relevant links and discussions regarding Golang initiatives we could engage in:

Proposal: Make Go2 better implement the Object-capability model for security -- Link
Master Issue of Go1 Issues to consider -- Link
Proposal: spec: remove complex numbers -- Link
Proposal: use a value other than nil for uninitialized interfaces -- Link
Proposal: Go 2: Add typednil keyword for checking whether an interface value is a typed nil -- Link
Proposal: Go 2: capability annotations -- Link
Proposal: Go 2: read-only types -- Link
Improve reflection system (so we can complete go2gno and gno2go)

Things we consider for post-release versions of Gnolang (Gno1.x)

Things above
Support new types like bigints natively
Make gno2go similar to CoffeeScript/TypeScript and generate good usage Go code

There is a meta issue on the main repo that could help a lot addressing all those topics, see: gnolang/gno#972.

Talent Hiring and Performance Evaluation Libraries

Goal

The goal of this project is to develop a series of libraries that enable efficient management of talent hiring and performance evaluation based on code. By leveraging code, we aim to achieve greater transparency, collaboration, and alignment in the evaluation process. Additionally, we intend to facilitate integration with on-chain project management systems, such as the Evaluation DAO (gnolang/gno#407) and Gnodes (gnolang/gno#382), to promote public visibility, accountability, and alignment with OKRs. The libraries will also be designed to seamlessly integrate with an upcoming technical test platform, where individuals can anonymously complete Gno-related puzzles and enter the hiring pipeline upon successful completion (gnolang/acs#1, private).

Inspired by the principles of unit tests and regression tests in code, this project aims to create a continuously improving talent hiring and performance evaluation system. By leveraging code and community collaboration, the libraries enhance transparency, collaboration, and alignment in talent acquisition and performance management. The project embraces a long-term approach, ensuring the system evolves over time to meet changing needs and drive continuous improvement.

Objectives

Collaboration: Enable collaborative evaluation and improvement of the hiring pipeline, performance evaluation criteria, and Gno-related puzzles. This includes allowing individuals to submit pull requests (PRs) to update their scorecards, OKRs, and puzzle content, as well as review PRs from others. Moreover, fostering collaboration will involve enhancing the set of questions asked during interviews and creating engaging puzzles through collective input.
Composability: Design the libraries with composability in mind, ensuring that different engineering roles (e.g., devrel, code developer, tinkerer) can leverage the system. While each job may have specific requirements and onboarding processes, there should be a core set of shared requirements, OKRs, and onboarding materials for all engineering roles.
Transparency: Develop a framework that promotes transparency in talent hiring and performance evaluation. The project aims to open-source the code, making it publicly accessible on GitHub. This will enable interested individuals to review and contribute to the process. During the off-chain phase, the repository can remain private, and certain parts, such as the hiring questions, can be kept private even when transitioning to an on-chain environment.

Implementation

The initial phase will involve developing the libraries in pure Go. This will facilitate off-chain, private implementation for testing and refinement. The libraries will focus on human-centric aspects, ensuring alignment with the talent hiring and performance evaluation requirements, including OKRs and the integration with the technical test platform. Later stages may include integration with other systems, emphasizing the collaboration and transparency aspects discussed above.

Deliverables

Open-source libraries in Go for talent hiring and performance evaluation.
Detailed documentation, guidelines, and sample code.
Integration recommendations for on-chain project management and the technical test platform.
Continuous improvement through community contributions.

Conclusion

The talent hiring and performance evaluation libraries aim to enhance alignment, transparency, collaboration, and composability. Integrating with on-chain project management and the technical test platform, this project empowers organizations beyond AiB to make data-driven decisions in talent acquisition and performance management.

Gnochess

Original Proposal: gnolang/gno#611 (comment)

Project Overview:

The Gnochess project aims to create a comprehensive example within the Gno ecosystem, building upon the discussions held during EthCC Paris. The primary objective is to develop a functional Gnochess product that serves multiple purposes and showcases the capabilities of the Gno platform.

Key Objectives:

Comprehensive dApp: Create an end-to-end decentralized application (dApp) called Gnochess, which goes beyond markdown rendering. This dApp should encompass a dynamic web interface, potentially extending later to include a mobile app and CLI through an accessible API.
User-Centric Design: Prioritize usability and a positive user experience for individuals unfamiliar with web3 technologies. Implement features such as an automatic faucet mechanism to streamline the onboarding process for non-web3 users.
MVP for GopherCon US: Develop an initial Minimum Viable Product (MVP) version of Gnochess in time for the GopherCon US event scheduled at the end of September. This MVP should highlight the core functionalities and provide a hands-on experience for attendees.

Project Milestones:

~~Reserve the domain "Gnochess.com".~~
~~Create a standalone repository to house the project's source code, documentation, and related assets.~~ -> https://github.com/gnolang/gnochess
Craft the necessary smart contracts to power the Gnochess dApp, ensuring seamless interactions and transactions.
Design and develop the web application, focusing on a user-friendly interface and smooth navigation.
Set up production and pre-production environments to facilitate testing and deployment.
Bonus: redirecting from "chess.gno.land" to the Gnochess application.

gfanton's Onboarding Journey

Welcome to My Onboarding Journey!

Hello future contributors 👋

Embarking on this project? Follow my footsteps. From the initial setup to my first GNO contract, I will try to document my entire onboarding experience right here.

So grab your favorite beverage ☕️, sit back, and join me on this expedition!

Berty's dSocial Builder Journey

This documents the continuing journey of Berty into Gno.land. This follows from our previous journey to create Gno Native Kit (formerly called GnoMobile).

The goal of dSocial is to create a test bed for building decentralized social media type of applications and experimenting with smart contract integrations around social media features. This test bed is not intended to be a polished end-user app but to experiment and stress test technical issues in using Gno.land related to implementing decentralized social apps.

The first version of dSocial will include the basic Twitter-like features like: post, react, notification, mentions, etc. dSocial will be built for mobile using the Gno Native Kit framework, but we will also include a minimal desktop app and a read-only web version.

Additional R&D issues we will investigate are:

integrating a DAO moderation feature
implementing a notification system using the “notifs core” code that is under development by the Gno core team
studying the scalability of smart contracts and the potential solutions involving Merkel trees

You're invited to follow our Journey where we will document our experience using Gno, writing realm code, and track our issues and R&D results. 🚀

GnoMMODE (MMORPG experience)

GnoMMODE (Massively Multiuser Online Decentralized Ecosystem)

Abstract

Taking inspiration from the compelling shared universes of Massive Multiplayer Online Role Playing Games (MMORPGs), I propose a novel concept for the Gno blockchain platform. I envision Gno as an expansive, interconnected digital realm—an ecosystem shared and actively shaped by its participants, reflecting the shared experiences of an MMORPG world, but within a decentralized context. This vision comes to life in what I'll term the "GnoMMODE"—the Massively Multiuser Online Decentralized Ecosystem. It aims to present the blockchain as an evolving visual representation, serving not only as an interactive interface but also as a new perspective of our participation in the blockchain universe.

Narrative

In an MMORPG, every player contributes to a shared world, and their actions create impacts that accumulate over time. Similarly, on the Gno blockchain, every participant leaves an immutable trace on the ledger through their transactions and smart contracts. I propose to transmute this abstract data into a dynamic visual experience, converting each Gno transaction into a building block for the GnoMMODE world.

Users can navigate this virtual incarnation of the Gno blockchain, observing areas where significant transactions have occurred, identifying 'hot zones' of high activity, and gaining real-time insights into the network's operation. It's a fresh take on the MMORPG concept, tailored to the decentralized blockchain environment—a unique convergence of data, gaming, and social interaction.

Significance

The GnoMMODE is not just an innovative user interface for blockchain interaction. It also serves as a powerful tool for understanding and communicating the dynamics of the blockchain. By presenting the blockchain as a shared, evolving environment, I believe it can become more approachable and engaging for newcomers, facilitating easier onboarding and discovery of the Gno platform.

From a scientific standpoint, the GnoMMODE can provide valuable insights into blockchain activity patterns, serving as a unique research tool for academics, data scientists, and blockchain developers. It can also foster a stronger sense of community among Gno users, highlighting the collective nature of the blockchain through the shared MMODE experience.

Feasibility

Given Gno's advanced smart-contracting capabilities, creating such a visual representation is within our reach. All the necessary data for constructing and continually updating this MMODE world is readily available on the Gno blockchain itself. New transactions and smart contracts would act as the continual source of new content, each one being translated into an in-game action or event.

The primary challenge lies in designing an engaging user interface that can render this MMODE world in a visually appealing and intuitive manner. This would necessitate collaboration between blockchain developers, game designers, and user experience experts.

Conclusion

The GnoMMODE concept represents a bold reimagining of blockchain interaction, blending the worlds of blockchain, gaming, and social media into a comprehensive, immersive experience. It's not just a visualization tool—it's a new way of seeing and engaging with the blockchain. It expresses the communal ethos inherent in the blockchain and offers a potent symbol of its potential to transform our digital lives.

Gno code coverage and plan improve it.

Gno code quality status

We have analyzed and executed all the existing test cases for the Gno repository to evaluate the current status of the project. We observed that the average code coverage for the project is around 60%. There are several directories that either have not been tested or lack test code.

Source code have many issues detected by static analysis tool.

Based on our analysis, we believe that to enhance the quality of the project's source code, we can contribute the following actions:

Perform static testing for any code changes.
Fix bugs identified by static code analysis.
Write integration and unit test scripts to improve code coverage.
Set up continuous integration and continuous delivery (CI/CD) for the repository to ensure that test cases pass with each new code update.
Create Regression testing plan

Onbloc's Builder Journey

Welcome to the Onbloc's Builder Journey!
This issue is a comprehensive introduction to Onbloc and a place where you can expect regular updates from us.
I hope you find this issue helpful to get to know about Onbloc, and we very much look forward to collaborating with you! Let's gno!

Introduction

Onbloc is a software development company that specializes in developing essential public infrastructure tools for the Gnoland blockchain ecosystem, including Adena (a non-custodial wallet), Gnoscan (a blockchain explorer), and Gnoswap (a decentralized finance platform).

Our goal is to play the role of ConsenSys for the Gnoland ecosystem. The importance of providing reliable key infrastructure tools such as MetaMask and Infura has been proven by the impactful contributions that ConsenSys has made to the success of Ethereum. These essential tools should be made available to the developers and dapps, free of charge, to accelerate the adoption of a blockchain ecosystem. We believe that the developer-centric design philosophy of Gnoland has the potential to place it as one the most widely-adopted smart contract platforms in the world, and we're committed to supporting this initiative by providing these tools for its ecosystem.

We're currently a team of 9 strong individuals with diverse backgrounds in the blockchain industry including Web3 projects, crypto exchanges, consulting firms, incubators, and infosec institutes, with an average career of 6+ years. Our members are firmly aligned with the vision of onboarding the masses to Web3. To achieve this goal, we believe that designing a quality UX/UI is essential for Web3 infrastructure services, an area in which we possess expertise.

This is our team member's Github handles:

Dongwon Shin (CEO) - https://github.com/dongwon8247
Peter Yoon (CSO) - None
Blake Lee (Senior Blockchain Developer) - https://github.com/r3v4s
Jinwoo Choi (Full-stack Developer) - https://github.com/jinoosss
Byeongjoon Lee (Core Developer): https://github.com/notjoon
Kyungsu Lee (Product Owner): https://github.com/akstar82
Andrew Kang (Project Manager & Research): https://github.com/adr-sk
Joon (Technical Advisor): https://github.com/mconcat

Onbloc links:

Website: https://onbloc.xyz/
Twitter: https://twitter.com/onblocxyz
Blog: https://medium.com/onbloc - We released a quarterly report! (Link)

Products

I'll briefly explain our products with related links here. You can find detailed milestones of each product in our Grants Program Submission (Link).

Adena

Adena is a friendly, non-custodial, and open-source wallet for the Gnoland blockchain. Adena currently supports a variety of wallet functionalities including creating/restoring wallet, viewing/sending/receiving tokens (including GRC20s), signing Gno realms, displaying transaction history, interacting with dapps, supporting ledger, google login, multi-network/account, the in-app faucet, AirGap Accounts, and more. We're working on adding new features such as GRC721, notifications, and more. Also, we're exploring a way to support new and more secure signing methods using std.Session.

Adena links:

Website: https://adena.app/
Chrome Webstore: https://chrome.google.com/webstore/detail/adena/oefglhbffgfkcpboeackfgdagmlnihnh
GitHub: https://github.com/onbloc/adena-wallet
Docs (User Guide & Integration): https://docs.adena.app/
Twitter: https://twitter.com/adenaapp
Blog: https://medium.com/@adena.app
Developer Discord: https://discord.gg/XzJMXXfrS9

Gnoscan

Gnoscan is a blockchain explorer for the Gnoland blockchain. Gnoscan currently supports on-chain activities in the main such as Monthly Active Accounts, Monthly Active Boards (/r/demo/boards), Newest Realms, and Daily Transaction graphs. Also, you can find detailed on-chain information that has been converted into a user-friendly format, making it easily readable, such as Account Details, Realm Details (i.g. /r/demo/users) and Token Details (i.g. foo) with raw contract code lines.

Gnoscan links:

Website: https://gnoscan.io/
GitHub: https://github.com/onbloc/gnoscan
API Docs: https://api.gnoscan.io/swagger/ - This is a Gnoscan-specific docs now, but plan to make a new version for more general usage.
Twitter: https://twitter.com/gnoscan

Gnoswap

Gnoswap is an open-source concentrated LP AMM DEX built using Gnolang, aimed at providing the most simplified and most user-friendly LPing and staking experience, enhancing capital efficiency, for traders. Gnoswap is currently the primary project that the entire Onbloc team is focused on delivering. You can track our developments through the links below for GitHubs, Docs, and Blogs (we're releasing a series blog!). Please expect lots of updates on Gnoswap in this thread!

Gnoswap links:

Website: https://gnoswap.io/ (Yet to be open)
Interface GitHub: https://github.com/gnoswap-labs/gnoswap-interface
Contract GitHub: https://github.com/gnoswap-labs/gnoswap
Docs: https://docs.gnoswap.io/
Twitter: https://twitter.com/gnoswaplabs
Blog: https://medium.com/@gnoswaplabs

Mics

Things that will be helpful for coming developers and dapps.

Gnoland Token Resource: https://github.com/onbloc/gno-token-resource
Gno Core Issue Tracker: gnoswap-labs/gno#7
Gnoland Developer Portal: https://docs.onbloc.xyz/ (merged with docs.gno.land)

I'll use this hackerspace issue to regularly update on our journey on Gnoland, also the progress of our grants. Lastly, the Onbloc team has been loving & enjoying co-working with the core members and contributors of Gnoland. I'd like to say thank all of you for being in this bright and innovative ecosystem. Let's gno!

go-testsuite, a testing framework for existing and future Go compilers and interpreters

The goal is to provide a test suite which can be used to verify independently that a Go language implementation supports the Go specification.

The project will be mainly a collection of self-contained Go sample programs like:

package main

func main() {
    println("hello", 3+2)
}

// Output:
// hello 5

And the scripts to build and tests existing toolchains against those examples.

Toolchain candidates:

Golang Go compiler
tinygo
gccgo
gnovm (gnolang)
yaegi
gno-rs (internal gnolang)
parscan (internal gnolang)
...

We can start to populate the sample base with various projects regression tests already in that format (gno, yaegi), and continue add relevant examples over time.

This project could be also to provide a framework for comparing other aspects like performances or other features.

database/sql driver

It would be enjoyable to have a database/SQL interface compatible with low-level types for creating optimized libraries. One possible solution is an AVL ORM, as suggested in this link: gnolang/gno#1467.

@ajnavarro, since you worked on an SQL server for Git, do you have any feedback?

In the future, it might be beneficial to have a native stdlib type that supports a small SQLite by default, like import "database/sqlite"; var db sqlite.New(). However, before considering this, let's explore the possibilities with pure Go.

Chain activity visualizer

Description

This idea, the same with #53, is something that's been on my mind for a few months now. We have tools in the gno ecosystem to sufficiently manipulate and extract transaction data (tx-archive, tx-exports, tx-indexer...).

It would be great to visualize this data somehow, similar to how Mintscan visualizes IBC transactions. Of course, it doesn't need to be this sophisticated, but perhap the initial scope of the project can be:

A user can see the most used Realms (bubble chart)
A user can see the most imported Packages (userland / sys...) (bubble chart)
A user can see interactions between Realms and Packages (graph, node interaction, similar to Mintscan)
A user can pick an address and see interactions with Realms (isolated address, every realm)
...?

Looking for feedback
@ajnavarro @alexiscolin @waymobetta

Multiuser Gno REPL

We can create a proof of concept that showcases the manipulation of Go objects by multiple individuals without relying on a blockchain.

This demonstration would effectively illustrate a crucial concept for Gnolang without explicitly discussing Web3.

Being inside a Gno/Go VM.

Related with #4, potentially an alpha version of it.

Go(d) Mode

I had an idea the other day to make it even easier for Go developers to start creating Realms and packages for the Gnoland ecosystem, using standard Go tooling, IDEs, and existing integrations.

This idea is still rough on the edges, but I wanted to share it with you all.

These will be the proxies with the web3 world using Go(d) mode (alias for Go Diction Mode, pun intended):

Gomod proxy

To be able to import and use libraries on a Go program, we can use a special Gomod proxy that will be able to retrieve libraries directly from the chain. You can see a PoC here: gnolang/gno#727

Std library

That Gomod proxy would be able to provide any kind of library we want using a specific package name. We could create a mock, Go-compatible std library that could be used directly on Go programs, with special methods used to mimic chain changes to be used on tests allowing developers to test their realms off-chain using standard Unit Tests.

Special libraries like time

For these libraries, we have to think about how to mimic blockchain behavior on unit tests. We can implement the Clock interface mimicking the expected blockchain behavior for the specific case of 'time'.

Special tokens like basic types

We could create a package with implementations of these types, just like BigInt is implemented. When translating to Gno, we can modify the AST to use the basic type implemented in Gno instead. Other special language tokens might have a workaround available to use them directly in Go, others won't be possible.

Publish

We should create a special gno command able to publish Go projects as realms or libraries. It could be something like gno publish PATH. That command will be in charge of validating that the used Go syntax is compatible with Gno (no goroutines or unsupported functionalities like generics), translate to .gno files, and upload it to the chain (if no -d or --dry-run flag is provided).

Pros and Cons

This will make it easy to create Realms and packages for Go developers because they won't need to change almost anything from their day-to-day workflow. Local testing will be much easier because we will have to focus on local development mocking blockchain behavior.

A con is that users may not be able to use all the extra functionality provided by Gno language.

decentralized social networks: empowering user-centric coordination

Social networks and messaging apps often fail to meet our evolving needs. Our vision is to prioritize user experience in decentralized social network apps, ensuring security and resilience in the Web3 era.

In the workshop, we will explore topics such as UX enhancements, simplifying crypto complexity, performance optimization, privacy, resilience, anti-censorship measures, reputation systems, overlay networks, specialized relay nodes, and off-grid communication. By focusing on UX design, streamlined crypto processes, optimized performance, privacy considerations, frictionless mobile interactions, and leveraging relay nodes, we can create a decentralized era that caters to non-tech users.

Let's organize a public workshop soon to discuss these topics together and shape a future where mobile phones serve as the primary device for seamless and frequent interactions with Web3.

cc @Ticojohnny @michelleellen

Brainstorm -> visual debuggers?

A beneficial topic for the project that could be explored with the help of niche experts is the development of visual tools to enhance the Gno experience.

What visual debuggers or tools would be most beneficial for debugging GnoVM or Tendermint2?

Some initial ideas:

A dependency graph can be generated using static code analysis, similar to how Go handles its dependencies.
Profiler flamegraphs to provide a visual representation of the execution of a program, similar to pprof.
TXs visualizer, maybe as an indexer feature. Maybe focused on the state more than on the contract-contract interactions?
Runtime datastore consumptions.

`gnols`: A Language Server for Gno!

Hi, everyone!

I’m a big fan of Go and I’m looking to get more involved in the web3 space, so naturally I found the Gno project.

While getting acquainted, I realized that there were IDE-like features that I missed when working on Gno files (especially with being unfamiliar with the standard library).

I saw Gno for VS Code, which is a great start, but I’m a Sublime Text / Neovim user.

So, I figured I’d experiment with an LSP implementation—gnols. The ultimate goal is to make these features available to all contributors regardless of editor preference.

It’s still very much experimental (about 2 days of work), but I thought I’d share my progress here.

I’m going to be working on tutorials for getting this set up, starting with Sublime Text and Neovim.

Hover Tooltips	Autocomplete

In-editor documentation for all exported symbols in the Gno standard library.	Autocomplete for all exported symbols in the Gno standard library.
Diagnostics	Formatting

Real-time precompile & build errors in your Gno files.	Format Gno files with the tool of your choice.

Add a "cognitive trust" score and linters.

Let's explore the idea of measuring "cognitive trust" in projects, inspired by "cognitive complexity" linters. By identifying good and bad patterns among Gnolang contract developers, we can enhance our environment for building highly trustworthy apps and systems.

It's not just about scoring contracts; we want to make smart choices in VM features to minimize the risk of untrustworthy code. Our goal is to make it nearly impossible to create such code.

Considering our mission and unique advantage, let's document this approach. We could even measure cognitive trust in other languages and provide scores.

To improve contract quality, let's create our own set of linting rules. This will facilitate static analysis, promote unambiguous patterns, and reduce the cognitive load of working with multi-contract scenarios.

Your feedback and any existing work links are welcome. We might even consider sponsoring a PhD research project to delve deeper into this concept.

Related with #17 (comment)

Gnoffee, coffee-script for Go and Gno

Introducing Gnoffee: Empowering Go and Gno with Seamless Feature Integration

Gnoffee is a powerful standalone tool designed to effortlessly enhance Go and Gno projects by generating code and seamlessly integrating new features. With Gnoffee, you can elevate your development process to a whole new level, easily adding functionalities without the hassle of manual coding.

Easing test of new features from #15.

Here's how it works:

$ gnoffee compile main.gnoffee > main.go
$ cat main.go
package main
import "fmt"
...

Stay tuned for more exciting details as we delve into the remarkable capabilities of Gnoffee!

"gno serve"

Introducing Gno's "serve" Subcommand and Content Import/Export:

Use gno serve to start a local Gnovm server with Gnoweb for testing and development without a real blockchain.

For easy progress management:

Export content: gno export [filename.md] to save server content.
Import content: gno import [filename.md] to resume work from imported content.

Seamlessly migrate to a live blockchain when needed. Simplify your development with Gno's powerful features.

Suggested flow

start gno serve
add your contract
interact
then, gno export > tx.md
and, gno import < tx.md

Addresses gnolang/gno#972
Depends on gnolang/gno#1016

Teritori's Builder Journey

Welcome Teritori team to the Gno.land hackerspace. The place to introduce yourself and document your journey in Gno.land as contributors and builders of the Gno.land Moderation DAO.

Proof of alignment / affinity clusters / character compatibility

The Proof of Contribution and Evaluation DAO is working on a governance system that uses a network of DAOs with tiered memberships. Our goal is to have skilled decision-makers in the top tiers who can build a secure and sustainable ecosystem.

Currently, we assess contributors by collaborating with them over time. We're looking for new ways to do this better.

One idea is to review past governance votes, but we need to watch out for bias and conformity.

To balance diversity and alignment, we aim to have a diverse DAO network and use "forkability" as a built-in system.

If you have ideas or know of similar approaches that focus on shared affinity rather than a single score, please share.

cc @MichaelFrazzy

gnolandc, onchain REPL, a.k.a., "gno shell"

RPC-Based Gno REPL Proposal

"RPC REPL" proposes using RPC calls against a remote node instead of an in-memory virtual machine, offering new possibilities. It can potentially merge with gno repl for a unified tool with local node support.

Related with #24
Related with gnolang/gno#1016

cc @ajnavarro @gfanton

META Ideas

Concepts, UIs, and hybrid dApps

GnoMMODE (Massively Multiuser Online Decentralized Ecosystem) -- #4
Oracles managed by a DAO -- #3

Integrating AI into Blockchain(Draft)

The landscape of Large Language Models (LLMs) is rapidly expanding, and integrating native AI capabilities into the blockchain is a forward-thinking move:

Enhanced Productivity: AI has the potential to significantly boost individual productivity across various creative domains, such as writing and art. Users can leverage smart contracts to access a suite of services, enhancing the creative process and output on chain.
Governance and Operations: AI is poised to become an essential tool for every Decentralized Autonomous Organization (DAO), facilitating improved production and governance. The incorporation of AI can streamline decision-making processes and automate administrative tasks, enabling DAOs to operate more efficiently.

The strategy's core is to integrate AI functionality as an intrinsic component of the blockchain ecosystem. The (draft) proposed objectives include:

Simple Interactive AI Chatbots: Deploying a user-friendly, on-chain chatbot analogous to ChatGPT through a interface of realm.
AI Agents for Task Automation: Establishing an on-chain AI agent adept at performing tasks such as computational problem-solving, responding to inquiries, and crafting Non-Fungible Tokens (NFTs), among others.
(TBD)Diversified LLM Ecosystem: Creating an expansive ecosystem that includes a variety of LLM services beyond the offerings of OpenAI. This initiative aims to foster a competitive marketplace for LLM providers on the blockchain.

META Multinode Testnet Initiative

Join the main issue for centralized discussions and related pull request links.

Our goal is to create a multinode testnet as a community initiative. Please contribute your scripts and content at this location.

Zack's Tinkerer Journey

Introduce yourself and your goals.
Use this issue to update your progress and link to relevant updates.
We may write a summary blog post later.

Release the auto-merkelized state persistency feature as a standalone library.

The idea would be to reduce the size and complexity of https://github.com/gnolang/gno/tree/master/gnovm/pkg/gnolang the state management system into its own library, i.e., github.com/gnolang/gno/gnovm/pkg/gomerkleizer.

It could be used by Go programmers to replace sqlite for some projects.

Example in `sqlite`

package main

import (
	"database/sql"

	_ "github.com/mattn/go-sqlite3"
)

func main() {
	db, err := sql.Open("sqlite3", "./example.db")
	if err != nil {
		log.Fatal(err)
	}
	defer db.Close()

	_, err = db.Exec("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, age INTEGER);")
	if err != nil {
		panic(err)
	}

	_, err = db.Exec("INSERT INTO users (name, age) VALUES (?, ?);", "John Doe", 30)
	if err != nil {
		panic(err)
	}

	rows, err := db.Query("SELECT id, name, age FROM users;")
	if err != nil {
		panic(err)
	}
	defer rows.Close()

	for rows.Next() {
		var id, age int
		var name string
		err = rows.Scan(&id, &name, &age)
		if err != nil {
			panic(err)
		}
		fmt.Printf("ID: %d, Name: %s, Age: %d\n", id, name, age)
	}

	err = rows.Err()
	if err != nil {
		panic(err)
	}
}

Example in `gomerkleizer`

package main

import (
	"github.com/gnolang/gno/gnovm/pkg/gomerkeleizer"
)

type User struct {
	Name string
	Age int
}

type DB struct {
	Users []User
	// ...
}

func main() {
	var db DB
	err := gomerkeleizer.Open("./state.db", &db)
	if err != nil {
		panic(err)
	}
	defer db.Close()

	db.Users = append(db.Users, User{"John Doe", 30})

	for _, user := range db.Users {
		fmt.Printf("Name: %s", Age: %d\n", user.Name, user.Age)
	}
}

gnoterm

Gnoterm is a tool that simplifies Gno.land blockchain exploration. It offers the convenience of navigating gno.land using a graphical browser, enabling source inspection, documentation generation, and generating copy-paste friendly command lines for gnokey. Additionally, Gnoterm provides advanced capabilities, such as making custom RPC calls and accessing Golang libraries developed by the community.

It's a different option from logos, with fewer purity constraints and no need to wait for dependencies to be developed. This makes it an ideal starting point with more flexibility and a faster RoI.

Inspired by the "Links{,2}" text browsers and the 'berty mini' tool from Berty, which simplified local protocol development without requiring a mobile app, Gnoterm aims to be an essential tool for developers and users. Its goal is to provide enhanced debugging features and a user-friendly experience for exploring the Gno.land blockchain.

Main Goals of Gnoterm:

Offer a text-based alternative to the web browser
Provide a platform for experimenting with new user experiences that may become standard on the web interface
Facilitate building Golang clients, including custom versions of gnokey

Key Features:

Explore packages/realms
"Open" a realm (index)
Render the Render() with terminal markdown renderer
Option to read the source code
Generate man page automatically using gno doc
Allow straightforward endpoint calling

Bonus Features:

Auto-complete
Integrated REPL features
List and inspect variables
Navigate between dependencies
Non-interactive mode
...

@gfanton is temporarily assigned to explore this tool during his onboarding. However, the task may be unassigned later if a more suitable role is identified for him or if his work doesn't provide a complete solution.

Formal verification of contracts.

We can make formal code verification convenient for both local work and automatic tests displayed when browsing contracts onchain. This increases safety for developers and users.

There have been relevant PhD research projects at a school in Paris that I used to visit. See https://team.inria.fr/hycomes/publications/publications-on-formal-verification/.

I'll keep this issue open to gather feedback and gather links to existing work on formal verification in Go. I plan to schedule a meeting with the school to explore collaboration possibilities.

State / merkle tree visualizer

I remember such amazing tools developed in the IPFS ecosystem to visualize merkle trees and CIDs in general. It was both useful for educational purpose but also for debugging.

Feel free to share existing projects that we could potentially adapt for our case.

Personally, I’d love something working in CLIs.

Run Gnokey on TinyGo

Develop a proof of concept (PoC) to verify compatibility between gnokey's current implementation and the TinyGo runtime.
Once the PoC is complete, explore simple methods for incorporating "authentication," such as:
- Utilizing a physical keyboard
  - https://github.com/sago35/tinygo-keyboard
- Implementing a button-based system
- Generating in-memory sessions that are authorized by the primary key, using the new account sessions system mentioned in this link: GitHub - gnolang/gno/issues/1499

Indexer for Extracting Source Code from Testnet Blocks to GitHub

Objective:

I propose the development of an indexer designed to subscribe to new blocks on our testnets. The primary function of this indexer would be to extract the source code of the uploaded packages from these blocks and then commit them to a dedicated GitHub repository.

Rationale:

Having the source code on GitHub offers multiple advantages:

Allows for easier exploration and understanding of the code without directly querying the testnet.
Facilitates static analysis to ensure the code's quality and safety.
Enables the testing of our tools on a larger, more diverse codebase, thereby increasing their reliability.

Inspiration:

A point of reference for this endeavor could be tx-exports that I formerly maintained. It primarily focused on archiving blocks. While it had its limitations regarding speed and efficiency, the idea behind it remains solid. Leveraging better infrastructure and a more sophisticated transaction indexing system could greatly enhance its performance and usefulness. (@Milos and @Albert for insights on potential improvements)

I believe that this tool would be a significant asset to our development and analysis workflows. Eager to hear thoughts and potential approaches!

Gno file compatibility with Go tooling

gnolang/gno#472 introduced linter support on the repository. These are however still not enabled for .gno files. Forking the linter to allow it to run also on gno files is probably impractical; and there also remains the issue of all other Go tooling which would be useful but doesn't currently work. For the scope of this issue, I think the tools which would be very much needed in Gno for a pleasant development experience are linters (golangci-lint, revive, staticcheck ...) and gopls (for text editor autocompletion, etc.)

While some tooling does have purpose in being rewritten to adapt to gno, the Go ecosystem is pretty vast, so it'd probably be better if there was a way to have a "compatibility layer" where the rest of the tooling can operate.

My idea: create a command in gnodev which creates a FUSE filesystem with go-fuse. In this filesystem we have both a GOROOT (containing the source code for the standard library, etc) and a GOPATH. The files inside are the gno files precompiled.

The filesystem would be "mostly" readonly, as formatters are better off executing directly on gno code (maybe supporting goimports-style functionality could be a bit trickier, though if anything this would be something to be done with gopls as in most editors that is what is currently providing the automatic imports), but the way I see it using a filesystem which can "emulate" a normal Go environment (by means of also in the future supporting remote packages and realms) is probably one of the easiest ways to make a lot of tooling work without having to maintain large amounts of code.

Very much open to different ideas as I can very easily see doing a FUSE mount having lots of impracticalities (full support only on linux, implementation of gopls in text editors would probably still mean changing extensions in text editors so that they can work on the gno files while having the tools like gopls and linters work on the FUSE-mounted files instead). The easier and less set up it requires to bridge existing tools to Gno, as well as for end users setting up their coding environment to have go tools in gno, the better.

What special features make sense for a smart-contract oriented VM ?

In relation with the prototype byte-code VM showcased in gnolang/parscan#1, the goal of this issue is to get answers to the following question:

What fundamental problems about smart-contract platforms could benefit (or not) to be tackled at a low-level VM level?

Or to be more specific, what features a VM should have in the context of a distributed smart platform:

checkpoint / restart (pausing / resuming from snapshot) ?
persistence (of what, and how is it defined exactly) ?
serialization of data? code?
code debugging means ?
code integrity checking?
merkleization (of what exactly ?)
backward/forward replay (i.e for speculative execution ahead of consensus) ?
parallelism / concurrency constraints ?
resource accounting (memory storage, instruction counting, gas cost)
deterministic execution?
other?

Idea: Oracles managed by a DAO?

I had an idea and I want to discuss if it makes sense or not:

Oracles are data feeds that bring data from off-the-blockchain (off-chain) data sources and put it on the blockchain (on-chain) for smart contracts to use.

I wonder if that might be possible to be done in Gno being managed in a decentralized way.

Example

Let's say that we have a DAO that is managing the interface for weather data. This DAO is in charge of keeping and updating the weather oracle data structure:

type WeatherOracleRequest struct {
    Lat string
    Lon string
    Units string
}

type WeatherOracleResponse struct {
    DataSource string    

    Lat string
    Lon string
    Timezone string
    Temp int
    TempFeelsLike int
    Humidity int
    Clouds int
    WindSpeed int
    [...]
}

These structures will be used by DAOs interested in creating an oracle service providing weather data.

With contract-to-contract communication, we should be able to create a package or realm that will fetch data from all registered oracles, aggregates them, and give an answer to the user's realm.

To incentivize data correctness, the main DAO realm that is aggregating the responses can keep a correctness ratio per oracle.

Still a lot of corner cases to cover, but in general, what do you think about this idea?

GNS (Gnoland Name Service)

Abstract

GNS intends to be a solution to have a decentralized registrar for names. It can be used for different things inside and outside the gnoland ecosystem, like gno package and realm names, decentralized web pages stored inside or outside gnoland, and other use cases where human-readable names improve the UX. All of this with no dependency on central servers.

Specification

Registrar DAO

The core of this functionality will be a Realm where the source of truth will be stored.
All domain names must finish with .gno

The registration record will contain the owner, the name as a unique key, and an undetermined list of A records that can be used for different use cases.

Buy a name

When someone starts the process of requesting a name, a bidding process will start. Anyone can check all the bidding processes that are open, and anyone can bid for any of these processes. The highest bid will get the domain ownership.

When the name is a special one as we will describe above, the price for the domain will be an average of all the previous winner bids (still to be defined).

Special names

We can reserve already existing names on GitHub/Bitbucket/Gitlab, to help developers to keep the same digital handler as they are normally using at web2.0.

That can be done by generating a signature for a specific domain/handler and adding that signature to a specific file inside the repository in a specific branch. We need external applications checking periodically that the signature is still valid on the specified Git services.

This will be done by creating a special GenerateRegistrarSignature Realm method that will return the signature needed to verify that your Handler is yours. After that, you can use that signature to register your .gno domain.

We should periodically load these handlers into the Realm to avoid others to register them without the mentioned signature.

General names

Anyone should be able to register any name that is not included in the previously mentioned blacklist at any point in time.

Renewal

All domains will have a TTL that will expire after a year. The price for the domain for the next year will be the same as the previous year (still to be defined). Special names won't have an expiration time, instead, we will check periodically that the used handler is still in use and with the needed signature on it. That check will stop when the owner has at least one package or realm registered using this name, and it is being used at least by one realm/library with a different domain.

DNS over HTTPS

We can create services around this Realm to provide other services, like DNS over HTTPS. That will fill the gap between web2 and web3, making it possible for browsers to resolve .gno domains.

A records

A records can be added, modified, or removed for the specific domain. They can be used for a bunch of use cases.

Subdomains

Any subdomain can be registered as a prefix of the domain by the owner. Each subdomain will contain its own list of A records.

Reentrancy

Reentrancy is a common source of vulnerabilities in other smart contract languages like Solidity.

Here's a Solidity example for reference: https://solidity-by-example.org/hacks/re-entrancy/

Common preventative measures in those languages are to audit code for use of the Checks-Effects-Interactions pattern, and use of libraries like OpenZeppelin's ReentrancyGuard. Code analysis tools like Slither also commonly test for reentrancy.

Given the utility in defi and other applications, it seems likely to me that Gnolang will one day support reentrancy in some form.

There's an open question as to whether reentrancy is currently achievable in Gnolang via MsgRun, which I plan to take a closer look at when time permits.

In the meantime, I wanted to create a thread on this topic and invite everyone to share their insights and ideas.

Varmeta's Unity SDK Journey

Introduction:

Meet our team members:
Anh Nguyen - Solution Architecture: www.linkedin.com/in/anh-nguyen-pham-hung
Quoc Bao - Unity Developer: https://www.linkedin.com/in/qu%E1%BB%91c-b%E1%BA%A3o-813359155
Pham Dat - Unity Developer:

Gno.land Unity SDK

Our primary motivation is to bridge the gap between blockchain technology and game developers. Unity is a widely used game development platform, and by providing a Unity SDK for Gno.land, we aim to streamline the integration of Gno.land's blockchain technology into Unity-based games and applications.

We envision this SDK to empower the Unity developers to leverage the strengths of Gno.land blockchain such as the simplified smart contract programming in Gnolang, the Proof of Contribution consensus mechanism, and the potential for long-term sustainability.

We also want to emphasize that this SDK will be built on the .NET Framework. This means that all applications written in C# .NET can potentially utilize this SDK.

.NET is one of the most popular application development platforms today. Ensuring SDK compatibility with .NET expands our reach, not just within the Unity game development community, but also to the broader community of .NET developers.

This also paves the way for integrating Gno.land's blockchain technology into a variety of other applications and services, not just limited to games but also extending to various other applications such as enterprise applications, web applications and beyond.

Through this expanded influence, we hope to promote widespread adoption and use of blockchain technology, thereby helping to enhance transparency and accountability across industries and processes.

Timeline

Start date: 2023/10/23
First release for core sdk in .net C#: 2024/01/23
Full release for unity sdk: 2024/03/01

Potential Challenges

Technical Challenges: Developing an SDK that works seamlessly with both Unity and Gnolang could present some technical hurdles. We need to ensure that the SDK is easy to use for Unity developers, while also maintaining the integrity and security of the Gno.land blockchain.

Compatibility Issues: Ensuring compatibility with all versions of Unity and various operating systems could prove to be challenging.

Adoption and Education: Once the SDK is developed, a significant challenge will be promoting its adoption among Unity developers. This will require comprehensive documentation, educational resources, and possibly community engagement efforts to encourage developers to start using the SDK.

Please follow this to check all the update from our progress.

`faucet.gno.land` - a faucet hub for the Gno ecosystem

Description

This is an idea that has been in the back of my mind for some time now, and I thought I'd discuss it on the hackerspace repo, as it might be a fun project for the team to do.

Basically, the idea is to build a faucet hub (hosted at faucet.gno.land) which would provide a clean UI interface for all the faucets in the Gno ecosystem (gno.land, staging.gno.land, different implementation partner testnets...).

Functionality:

Enable the user to select which network faucet they want to receive funds on (with a limit)
Provide field/form to enter the address manually
Show the balances of each different faucet (for each network)

Nice-to-have:

Support 3rd-party networks via PR (JSON structure: endpoint, image, etc.)
Show the user's balance (selected address) for the different networks (somehow in the UI)
~~Provide an option to connect an Adena wallet (and use the address from it)~~ (not necessary; keeping for history)

In the future, this can be expanded for funds other than native currency (ugnot).

The faucets are hosted on separate machines independently, so the UI would just be hitting the APIs of the faucet implementations (gnolang/faucet).

If development teams want to add their faucet to the app, they can just open up a PR and have it appear and working when merged.

Additionally, a Discord bot can be set up that will provide the functionality offered by the UI, but in message / command form over Discord.

Looking for thoughts
@waymobetta @leohhhn @dongwon8247 @alexiscolin @AidarItkulov

[RFC] Git integration for decentralized OSS and mixed go-imports (bonus)

Disclaimer: This is an early issue and not a current priority. However, with new team members and previous discussions, I wanted to create an official forum for future discussion.

Context: recently, we welcomed @ajnavarro to our team. Before joining us, he worked on the development of go-git. Another member of our core team, @harry-hov, has contributed to @git in the past and is now focused on porting go mod to gno mod by fetching gno dependencies from the chain, which differs from the way go uses git for this purpose.

Three initial exploration options:

To enable the go import of a gno contract with automatic transpiling of .gno files.
Same, but with generated type-safe Golang clients.
Degen: By using Golang's vanity URL feature, we'll switch to tendermint.org/gno to boost censorship resistance and migration flexibility. Exploring a git interface to deliver go sources via gnoweb, gnoland, or a standalone service is possible, but probably unnecessary.

Exploring an Enhanced Contract Storage System (Perfs)

Background:

Our current contract execution process works well, but we believe there's room for performance improvement, particularly in storage. The current key-value storage model, which combines RAM and Disk with lazy loading, presents potential opportunities for enhancement.

It's important to clarify that we're not proposing to replace how we store blocks; we're focusing on optimizing the representation of the state, which can be reconstructed by replaying the blocks. Think of this storage as a cache, and it's worth considering customizing it. In fact, there could even be competing strategies, as long as they maintain determinism and block compatibility.

Explorations:

Overlay File Systems: One intriguing idea is to explore file systems that operate similarly to overlay systems, like aufs, overlayfs, zfs, or btrfs. In this model, each new commit generates a new overlay with a Merkle proof. Eventually, we would only need to inspect the current state, taking advantage of kernel and file system features for caching and optimization.

Potential Performance Enhancements:

Batch Loading: Fetching related data in larger groups to reduce retrieval times.
Data Compression: Using efficient compression methods to save space and speed up operations.
Smart Caching: Storing frequently used data in memory for faster access
Parallel Processing: Handling multiple data operations simultaneously for faster access and updates.
Data Partitioning: Splitting data into manageable parts for more balanced and efficient storage.
Optimized Indexing: Fine-tuning database indexing to speed up data retrieval, especially in large datasets.

Share Your Insights:

If you have experience with Flamegraphs (I'll generate and share myself later it not yet done) or similar profiling tools, please share your results. Your insights can help us identify areas for potential improvement.

gnolang / hackerspace Goto Github PK

hackerspace's Introduction

Hackerspace

Goal

hackerspace's People

Contributors

Stargazers

Watchers

Forkers

hackerspace's Issues

GnoDesk

Blogs

Research

Events

Updates

Gnoswap

Adena

Patch Notes

Developer Portal

Gnolang 101

Overview

URLs

Key Features

Milestones

Support

December 2023

Introduction:

Products:

FanChain:

Here are some relevant links and discussions regarding Golang initiatives we could engage in:

Things we consider for post-release versions of Gnolang (Gno1.x)

Goal

Objectives

Implementation

Deliverables

Conclusion

Project Overview:

Key Objectives:

Project Milestones:

GnoMMODE (Massively Multiuser Online Decentralized Ecosystem)

Abstract

Narrative

Significance

Feasibility

Conclusion

Gno code quality status

Introduction

Products

Adena

Gnoscan

Gnoswap

Mics

Description

Gomod proxy

Std library

Special libraries like time

Special tokens like basic types

Publish

Pros and Cons

Suggested flow

Concepts, UIs, and hybrid dApps

Example in sqlite

Example in gomerkleizer

Objective:

Rationale:

Inspiration:

Example

GNS (Gnoland Name Service)

Abstract

Specification

Registrar DAO

Buy a name

Special names

General names

Renewal

DNS over HTTPS

A records

Subdomains

Introduction:

Gno.land Unity SDK

Example in `sqlite`

Example in `gomerkleizer`