ethereumcommonwealth / roadmap Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU Lesser General Public License v2.1
License: GNU Lesser General Public License v2.1
Ethereum addresses are exactly the same on all Ethereum-based chains, such are ETH, ETC, UBIQ, EXP, Musicoin, SoilCoin (not sure about RSK, didn't investigated yet).
This means that you can use one account (read: private key) for all chains. As the owner of 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8
, I also own an account with the same address on any of the above chains and can dispose of funds from it.
This means that if the address 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8
is the owner of the name dexaran.eth
in ENS, then you can perform a lookup in the ENS contract that is deployed ETH chain, but execute the transaction on any other of the specified chains.
In two words: you can send ETC to the owner of dexaran.eth
and he can access them without any problems.
I wish to create a service that will perform lookup on any of the existing ENS forks based on the name resolution. I will integrate it into ClassicEtherWallet and write a patch to MEW as well.
For example:
.eth
TLD for ENS.etc
TLD for ECNS.ubq
TLD for UBQ ENS.exp
TLD for EXP ENSIf ENS integrates with ICANN, I will change the search method so that any user can artificially choose which particular naming service he wants to use.
I believe that improving any of the Ethereum-based networks will be beneficial for the whole Ethereum ecosystem. I also believe that Ethereum Classic, UBQ, Expanse and others belong to the Ethereum ecosystem.
This is similar to how all crypto-currencies based on BitCore get benefits from updates like SegWit or Lightning.
It is obvious that the integration between chains is beneficial for both participants and increases the cost of both chains.
This is beneficial for users: each name will cost you in proportion to the currency rate of the network in which you buy the name. If the user doesn't care about the resolution he can just pick the cheapest one.
It also allows us to introduce new TLDs without affecting the original ENS.
We should came into agreement about what exactly resolutions would be assigned to each naming service. Currently, ENS uses .eth
, and ECNS uses .etc
. I propose:
.eth
.etc
.ubq
.exp
.musicoin
.rsk
(not really sure if RootStock needs ENS, but it's not a problem to deploy it)ETHLance is the future of work - a no-fee marketplace for buying and selling workforce (freelancing). Would be great having it on the ETC chain. This could eventually be extended to include the whole district0x network.
Ethereum Commonwealth is open for contributions, completely financially transparent development team with a decentralized DEX token voting decision making process. The following describes terms of contributions to Ethereum Commonwealth projects, defining milestones
and submitting requests for payment.
milestone
proposal to Ethereum Commonwealth roadmap.This section is for those who have a clear vision of how to improve Ethereum Classic protocol, infrastructure, ecosystem or build a valuable DApp or service on top of it.
To submit a proposal for Ethereum Commonwealth, go to the Roadmap issues and create a new issue. Place a title and briefly describe what exactly you want us to implement. Submit a new issue and leave it open.
We will review new issues and place a milestone
label on development proposals. We will pick the most important issues and resolve them one by one as soon as we will finish our ongoing in progress
projects.
If you have changed your mind and you no longer think that a submitted issue-proposal is worth resolving, then you should close the github issue.
milestone
proposal of Ethereum Commonwealth roadmap.This section is for those who have a willingness to improve Ethereum Classic protocol, infrastructure, ecosystem, solve one of the important problems of Ethereum or just to work on someone else's proposal for the sake of payment.
Look for Ethereum Commonwealth roadmap issues that are marked with milestone
label. If you have enough skills and a willingness to resolve one of them then you can comment your terms of service and payment request to the corresponding issue.
If your request is accepted, you can begin to contribute and receive your payment on specified terms. In case of conflict of interests or controversial situation you can submit a DEX token voting session to resolve it according to the default DEX voting decision making process: #1
Those issues that are marked as milestone
but not marked as in progress
or finished
are available for picking by third party contributors. You can submit your request for payment and terms of service at this issues.
Those issues that are currently marked as finished
do not represent any opportunity to contribute to. They are currently in final stage. If you have an idea of how to improve a finished
project then you can submit a new issue-proposal and discuss it at the new issue.
Those issues that are currently marked as in progress
are currently in development stage and there are contributors that are already working on them. These issues do not represent opportunities for improvements by third parties.
A full history of Ethereum Commonwealth financial operations will be reflected here: https://docs.google.com/spreadsheets/d/1-ibJXI9IfrkKloLgN6RHxoXeCbdqa9mti1afTcO1BQk/edit#gid=979560349
The ICO did not collected even a half of planned funding. As the result of this I'm proposing to extend the ICO by 1 month (until 8th September, 2017). You can vote for or against it. You should send your DEX tokens to one of those contracts that is corresponding to your position:
YES: 0x2a0f718a8977dbfab1e20fd5bf862854ae3ce427
NO: 0x572c4d25a1631f7865aad3274880ba64be141f0e
NOTE: This voting will end at 7th August, 2017 one day before the end of the DEX ICO and the decision would be made.
This is an implementation of a Multisig wallet smart-contract. This Wallet smart-contract is designed to store funds and restrict access to funds management.
The main goal of this wallet is to serve a storage of the official donations for the Ethereum Classic development.
A critical error is an error that can be directly exploited and violate the workflow of contracts or lead to a breach of contract operability. A critical error is an error, as a result of which the wallet owners lose access to the funds in the wallet, or the attacker gets access to these funds.
Any bugs that can occur in some specific circumstances and violate contracts workflow or lead to a breach of contract operability. A security vulnerabilities is an error, as a result of which the wallet owners lose access to the funds in the wallet, or the attacker gets access to these funds.
Any code flaw reports that can violate the contract's workflow.
This does not apply to getter functions and comment improvements.
Submit an issue at the Multisig contracts repo: https://github.com/EthereumCommonwealth/ethereum-classic-multisig/issues
The first person who submits the issue bugreport will be paid if the problem reported is considered to be an error.
For any questions: [email protected]
The reward will be paid in ETC (Ethereum Classic cryptocurrency).
Bugbounty is relevant from February 12, 2018 to February 19, 2018.
UBQ network: can not generate transaction. TypeError: hex.substring is not a function at Function.ethFuncs.sanitizeHex
. Works correctly in any other network.
Gas autoevaluation bug: replaces gas twice when clicking "Generate Transaction" if the input amount is different from the autoevaluated gas limit.
Adjust ECNS tx gasLimit
to 570000. (Working TX (570k gas) / Failing default TX (520k gas))
Evaluates hand-typed address as DexNS name. Relevant for adding custom token.
Requires node to be added when adding a custom token. Throws node not found
error when node is not found. Replace required node
property of custom token with an optional node
option. When node is not established (for example on Rinkeby testnet) set node to null.
UBIQ node is down (fixed with EthereumCommonwealth/etherwallet#19)
Ethereum Classic address-to-address messaging system release. Messaging system represents a smart-contract basic on-chain communication service wich allows to contact any other participant of the network absolutely securely.
The Messaging System allows crosschain interoperability, which means that you can send message from ETC chain to the owner of ETH, UBQ, EXP, Musicoin, RootStock or PIRL address. ETC smart-contract system acts as the core component of the system. Messaging System supports off-chain encryption via the asymmetric encryption algorithms.
Launch date: 29 Jan, 2018 - contract deployment date.
Originally this messaging system will be implemented at ClassicEtherWallet. Initial version will include a possibility to send and receive simple text messages between addresses.
Advanced functionality, such as message encryption, public key import/export will be added at further releases.
Education about building of crosschain services: read this article
Original implementation of the messaging system smart-contract by Ethereum Commonwealth: https://github.com/EthereumCommonwealth/Address-to-Address-messaging
Address-to-Address messaging system code at Ethereum EIPs: ethereum/EIPs#802
The following describes the details of the smart-contract based messaging system which aims to allow Ethereum users to directly contact the address owner without having to know who hi (she) is.
Ethereum lacks a central messaging system that will allow to contact an address owner directly. You can send him a transaction with ASCII message attached as data
but it is likely that address owner will not even try to recognize it as a text message. As the result there is no viable way to deliver a message to address owner directly.
This service is necessary in some circumstances, for example:
You sent someone a token, the existence of which this person does not know. It is likely that a person will spot an incoming ETH transaction, but there is no way that a person will spot an incoming token transaction or the fact that his balance of this token increases. You need to contact the owner of this address and ask to send your tokens back.
You sent ETC into someone's ETH address. The same situation as with tokens. It is likely that a person will not recognize an incoming transaction of an alternative currency. But he definitely can access it and send it back (or just go and sell it).
You spotted that someone have deployed a contract that is proven to be vulnerable. If you're a good guy then you want to contact an owner of the "vulnerable contract" and warn him that he is going to use a contract that contains vulnerability and his funds are at risk in this case.
You spotted that someone has hacked something. You would like to contact a hacker and kindly ask him to send everything back but the hacker likely will not respond if you will try to contact him via forums. I suppose that it is the most important case. On-chain methods of communication are the only way to securely contact a hacker or to respond if you are the hacker.
Basic address-to-address messaging smart-contract.
This is a simple smart-contract that stores messages mapped to addresses by id and a mapping that represents the last message id for each address. Last message id increases for the receiver address when this address receives a new message (there is no message at last_message_id
in fact... this represents a numeric id that will be filled with the next incoming message in fact). If the last_message_id
is equal to 0 then there are no messages for this address. If last_message_id
is equal to 2 then there are 2 messages at positions 0 and 1 for this address.
There is no possibility to edit, change, delete messages. This contract is not a messenger or a chat. This contract is an emergency way to contact an owner of a certain address when there is no possibility to contact him off-chain. As the result, editing and deleting messages has no reason because it will still be available via history of transactions.
Basically, there is no way to encrypt message on-chain because there is no way to hide an input call data. As a result, there is an additional field for attaching a public asymmetric encryption key. If the owner of a certain address has a desire to allow someone to contact him privately, then he can publish his public key at this contract and describe what type of key he has published at the "Key type" variable (for example PGP public key
or RSA 2048 bit public key
). Anyone else is allowed to look at the public key in the contract, encrypt the message outside the network and send an encrypted message on this contract.
Obviously, this contract can not guarantee that an owner of the address will receive a message. It requires to be supported by UIs. It is likely that an owner of a certain address will see a message if MyEtherWallet, MetaMask or Mist will display messages somehow (for example a certain number of last messages).
Also, it makes sense to standardize possible public key types. Ideally, UI should have a button "Send message to address" and "Send encrypted message to address" and distinguish public key, key type and then encrypt message automatically.
To vote for this item, send DEX tokens to this contract: 0x56696968c23cce54dfea7349c7d5c96e41f38e77
To vote for this item, send DEX tokens to this contract: 0xe2ddee6187d6e231ae540bd7eac2dbd83a7448d9
p.s. compiled with solc 0.4.17 + optimization.
bytecode keccak-256 hash 0x83a3636f93df74b400cf70ffe4f01835189b8c42df729068fe8695aab044eca9
Delegated to ETC Cooperative team.
As more and more updates to ETH (Ethereum) come out and additional capabilities in the blockchain are developed, who will maintain the code of the ETC chain? Will ETC move to a Proof of Stake model as well?
Well, even filename is not compatible.
Capital letters should be avoided in most places.
The blockchain explorer is intended to:
Display blocks, transactions, state of addresses and provide the rest of default blockchain functionality.
Ensure the easy addition of new networks compatible with the ETC. It is planned to support ETC, ETH, UBQ, EXP, PIRL, Rinkeby (testnet), Kovan (testnet), Morden (testnet), Ropsten (testnet), Callisto-test (testnet), Callisto chains simultaneously.
Display a full history of transactions of the given address.
Display DexNS names of addresses at any network.
Properly display the signatures of known events: Transfer
, bidding ENS events, NewMessage
of messaging contract ( #36 ), Transfer
of ERC223, ICO events of token mint and so on.
Ensure the easy addition of new known events signatures.
Get a history of messages of a given address by Messaging Smart-contract of ETC network: #36
Properly display internal contract invocations.
Display "amount at stake" at Callisto network (CLO only)
Display "current staking amount" at Callisto network (CLO only)
The main ECNS revenue is now a 0,5% comission from cancelled deeds. Note that the main amount of spent money is still burned. I mean sealed bids that were not unsealed during the reveal period.
It is technically possible to allow deeds to be cancelled after the auction will be closed. There is no need to keep deeds for more than 7 days (each auction will last for 4 days max).
We can collect the money from the unrevealed bids without any problems.
This contract system is an implementation of Ethereum-based naming service.
DexNS Name is a special structure that contains address of the owner, address of the destination (Name will be resolved into this address), metadata, signature (Keccak-256 hash of the name).
Contracts must provide the following functionality:
destination address
, metadata
, signature
.onNameOwnerChanged
can not become the owner of the name as a result of the transfer of ownership of the Name.A critical error is an error that can be directly used as a result of which:
A Name can be registered without payment.
Already-existing, not expired Name can be re-registered to another owner.
Name content can be managed by the address that is not currently an owner of the Name. (Name assignment can be managed by the address that is not currently an owner of the Name)
The consequences of the expiration of ownership of a Name could be avoided.
Other errors that can directly violate the workflow of contracts and lead to a breach of contract operability.
Any bugs that can occur in some specific circumstances and violate contracts workflow.
Any code flaw reports and suggestions that can improve DexNS contracts workflow. This bounty will be paid if the suggested solution will be implemented in final version of DexNS contract system.
Submit an issue at the DexNS contracts repo: https://github.com/EthereumCommonwealth/DexNS/issues
The first person who submits the issue bugreport will be paid if the problem reported is considered to be an error.
For any questions: [email protected]
I have withdrawn ICO funds. http://gastracker.io/tx/0x525d99f39a13dfc63a652945382b3ee152cee6ebe7e7ede65801b6fd504286c4
As I said earlier, I subtracted the amount of my personal deposit from the total amount of ICO funds. My personal deposit amount was 706.5 ETC. You can easily verify it because the amount of DEX tokens that I currently hold (on this address) is equal to 706.5
Ethereum Commonwealth funds are currently located here: http://gastracker.io/addr/0x52823e725a34d42e14a1b66fb67299C30c4d8Edf
The reason of doing it is I'm currently working on projects that I've announced and I started to hire.
I've already finished the ECNS and we are waiting for MyEtherWallet to support it.
I'm currently finishing the DexNS. I'm hiring developers to work on Decentralized Mining Pool, API endpoints provider and Classic Mask.
18dew currently contributes to the Classic Mask.
ICO is not over yet. During the ICO, I will transfer funds to this address: 0x52823e725a34d42e14a1b66fb67299C30c4d8Edf
This will be used as an official Ethereum Commonwealth address in future.
An opt-in decentralized court. Very useful in cases where smart contracts is not enough and non-biased human decision making is needed. It's also a good protection layer smart contracts can use if there is some issue, such as with theDAO, but this time it would be explicit in the contract that humans might get involved to intervene when there are mistakes in the code.
good afternoon . I save etc on the classicEtherwallet purse in order to get Callistro but I did not receive Callisto. tell me please when I see Callistro on my wallet?
Hello,
I found one project that proposes security enhancement to ethereum network, but I think Ethereum Classic can also benefit from this idea.
https://www.etherblue.org/whitepaper
I am wondering if it is possible to implement smart contract that allows to set withdraw limits on per day, week, month basis as addition security? Then the address owner can set the desired limits interacting with the smart contract.
Another use case can be repeated payments (for example each month) or payment on a certain date, like in the traditional banking.
Smart-contract auditing department of CLO & ETC (source code)
Callisto original announcement
5500000
(snapshot repo)cold staking protocol
implementation.smart-contract governance system
.After the CLO Hardfork №2, the development will be based on the built-in governance system and the proposals that will be accepted by the stakeholders.
The following is a proposal to define a protocol to solve a problem of a complete lack of possibility to communicate with an owner of a certain address on Ethereum CLassic, Ethereum, UBQ, Expanse or PIRL networks.
EIP 802: ethereum/EIPs#802
ECIP 85: ethereumproject/ECIPs#85
The following describes the main goals that are planned to be achieved to improve ClassicEtherWallet, the main web wallet of Ethereum Classic.
The Ethereum Commonwealth and Callisto team adheres to the policy of financial transparency.
We keep a complete financial history in an open document so that everyone can review it. Financial operations will be described at the above document. Financial operations are verifiable by transaction hashes.
Each financial operation of Callisto Treasury will be documented until an autonomous governance system is created (Planned HardFork №2).
Each financial operation of Staking Reserve address will be documented until Cold Staking is implemented (Planned HardFork №1).
Old financial report: https://docs.google.com/spreadsheets/d/12b5JgL1veCAvV1yLhmxDva80Gz3pA0OVSPw_uTf9aEQ/
New financial report:
https://cloudflare-ipfs.com/ipfs/QmbXgrCu8H21uVuQNjtqTHo4zBF8kB5NMK6GYL32JVD8qx
Is there any forum for discussion of upcoming research going on ETC labs?
Longterm sustainability of Callisto platform and CLO financial model.
The initial plan was to separate core features (financial: Cold staking/ utility: Free security auditing). Cold staking should bump the price. The higher the price is, the more effective security enhancement will be.
However, this is just a conception and it is far from guaranteed. Watching the EOS cenceptions I came into a conclusion that it may turn out that we will need to increase the value of Callisto platform at our own (regardless of what is going on with crypto industry globally). Taking the EOS model into account, I can propose the following:
Security auditing will require a smart-contract developer to hold an amount of CLO at his balance during the auditing process.
The more CLO a smart-contract developer owns, the higher the priority of his auditing request is.
Once the security audit is completed, the smart-contract developer can sell his CLO. Thus auditing remains "free". You can buy CLO, request audit, sell CLO (+/- volatility).
This ensures volume and liqidity as well.
DexNS, the first crosschain decentralized naming service for human-readable address resolutions and token-related services scalability improvement tool, has successfully passed the bug bounty and final changes were applied.
DexNS final version reference.
DexNS contracts are currently deployed on ETC mainnet. We are transferring names from the trial version now. Service will be officially announced at 25 Dec, 2017.
A final service will take a fee of 0,01 ETC per Name to resolve DDOS issues. All the fee funds would be distributed according to the Ethereum Commonwealth revenue distribution process.
Pre-definition period is the period of time before 1st September, 2018. The final version of smart-contract based voting and smart-contract based revenue distribution will be established at 1st September, 2018. It may require DEX token contract upgrade!
Each for-profit service outputs its income to the specified address (bursary). Once a month 65% of the balance of the "bursary" address will be moved to official Ethereum Commonwealth address to fund further development. 35% of the remaining funds will be distributed among the shareholders of the DEX token in proportion to their share.
The ECNS project is already finished. Unlike the ENS, it will not burn money, but put them in bursary.
Imagine that user have bidded 100 ETC for ECNS name but forgot to unseal bid during the reveal period. In this case 0,5% of the bid value will be returned to the user and 99,5% will be donated to the bursary.
Bursary receives 99.5 ETC.
Another user bidded 200 ETC for ECNS name and unsealed bid. In this case 0,5% of the bid value will be donated to the bursary and the remaining 99,5% of funds will stay at the ECNS.
Bursary receives 1 ETC.
I own 706,5 DEX of 3658.87. This means that my share is about 19%.
At the end of the month 65% will be sent to the official Ethereum Commonwealth wallet: 65.325 ETC total.
The remaining amount of 35.175 ETC will be distributed between DEX shareholders. Personally I will receive 35.175 * 0.19 = 6.68325 ETC.
P.S. I assume that percentage will change in future. I have raised a lot less that I supposed so I need to establish a self-funding mechanism for the team at the initial stage. I prefer to increase a percent of DEX holders to 70% and to decrease a percent of team funding to 30% after the pre-definition period.
I've seen that you are closing your ico. The supply of dex token is incredibly low. May be we need to introduce proof of stake coin supply growth? It looks to be possible with erc223.
It would be the first proof of stake erc223 token on ethereum.
Ethereum Commonwealth adheres to a policy of financial transparency.
We keep a complete financial history in an open document so that everyone can see it. Each financial operation will be reflected there. Each financial operation will be verifiable via transaction hash.
The document will be updated once a week.
https://docs.google.com/spreadsheets/d/1-ibJXI9IfrkKloLgN6RHxoXeCbdqa9mti1afTcO1BQk/edit#gid=0
I've seen that you prefer Viper adoption on Classic rather than solidity promotion. I'd like to recommend to start with creating an analogue of Remix online compiler.
https://gitter.im/SmartPool/Lobby
https://github.com/SmartPool
http://smartpool.io/
What should be done:
Deprecated in favor of Enhanced Free-of-Charge Auditing system.
One GETH client that will support both Ethereum and Ethereum Classic networks. It should also support all the testnets defined in Ethereum Foundation's version of GETH.
Source code of GETH is located here: https://github.com/ethereum/go-ethereum
Geth classic should support an additional --classic
flag:
$ geth --classic
Specifying the --classic
flag should reconfigure your Geth instance a bit:
~/.ethereum
on Linux for example), Geth will nest itself one level deeper into a Classic subfolder (~/.ethereum/classic
on Linux). Note, on OSX and Linux this also means that attaching to a running testnet node requires the use of a custom endpoint since geth attach will try to attach to a production node endpoint by default. E.g. geth attach /classic/geth.ipc. Windows users are not affected by this.User who vote from a contract could call Withdraw
, and in his tokenFallback
function vote again.
This will result in loss of tokens, as deposited[msg.sender]
is eventually reset.
This might be used by a malicious user to demonstrate a problem in ERC223.
The main purposes of this voting are:
If this voting system will succeed, then it will be used until 1st September, 2018. After this date a final version of voting contract will be deployed.
Special voting contracts will be deployed. Each contract will be associated with it's proposal. You should just send DEX tokens to a contract that is related to your desired proposal. You can withdraw your tokens from vote-pool contract at any time.
Vote pool contract source code is located here.
If you want to add any proposal to current voting session then you should deploy a vote pool contract and provide its address in comment here. Source code of the contract should be verefied also. Vote pools with not verified code wouldn't be added to the voting session.
NOTE: Keccak-256 hash of vote-pool contract runtime bytecode (with 0x prefix) is 96b45a5bb84ccbc251e6b393988f9f1e272d571d021864d9b190f0b99130bf60
The voting process will be divided into sessions. Each session will have its own timeframe and should be discussed on specified issues.
The voting results will be calculated by the balance of each vote-pool contract at the specified moment of time.
Vote-pool contracts are already established. In this voting session I'd like to get feedback from DEX token holders about further development direction. I'm currently working on finalization of ENS port for Ethereum CLassic (bug bounty), DexNS adoption (EIP 668), ERC223 improvements (there is a suggestion to use ENS reverse registrars for storing fallbacks) and other improvements. I'm planning to hire developer to port MetaMask for Ethereum CLassic in near future. I'm also planning to launch a serie of tiny bounty-contests (there is already a bounty desk for this team), because of I think that ETC needs more community/public adoption.
I'd like to get feedback about what do you prefer me to focus on?
To vote for this item, send DEX tokens to this contract: 0x9c227bd4bbc732b9d701399fb008eb6131662a6b
To vote for this item, send DEX tokens to this contract: 0x7f16e349850e8ffc822c19fcadfffdbe6ce62a2f
To vote for this item, send DEX tokens to this contract: 0xdb77b8146954653782578684b5730cc1f6ecf273
To vote for this item, send DEX tokens to this contract: 0x98b9276c172e40e95748a9aa4159e3a1735cbff6
To vote for this item, send DEX tokens to this contract: 0xa313edba5b956e70df83a641ea11697169fc4fd9
NOTE: Requires protocol upgrades!
To vote for this item, send DEX tokens to this contract: 0x4c77a5980a6fddd4c8180be7eb1513a011eb0a88
To vote for this item, send DEX tokens to this contract: 0x443df711c635b8a7dc75f7ba220e096842aed90c
To vote for this item, send DEX tokens to this contract: 0xe8ede33ba36343e04823b1e5c1762cba02f1f58c
To vote for this item, send DEX tokens to this contract: 0xe6aa960e5b59ed4af028e444fc2973eb9aa9249f
The result of trial voting №1 will be calculated at 25 July, 2017 at 10:00 UTC.
Trial voting №1 is extended until 29 July, 2017.
Gastracker sucks. It is always lagging. It is displaying -2714 confirmations of 12. It doesn't display token transfers. It doesn't display comments and address reputation. It doesn't provide any advanced functionality. It doesn't support testnets.
If you want to unite the whole Ethereum-core project's infrastructure with common services then it's your chance. Common wallet will be CEW. Common extension will be classicmask. We need common blockchain explorer with advanced functionality now.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.