A spec for the did:peer DID method.
Home Page: https://dhh1128.github.io/peer-did-method-spec/index.html
License: Apache License 2.0
This spec has moved to a new home. See https://github.com/decentralized-identity/peer-did-method-spec for the code, or https://identity.foundation/peer-did-method-spec/ for the rendered HTML.
The final version of the spec as it existed in this repo is tagged as version 1.0 in the new location.
I believe that it should be made explicit that developers should not make assumptions from a DID resolving method about its use.
o did:sov DIDs could be used both pairwise and anywise
o did:peer DIDs could be used both pairwise and anywise
We could include a note that states that publicly-resolvable (like did:sov) DIDs would typically be anywise, and non-publicly-resolvable DIDs (like did:peer) would typically be pairwise
That note could include a warning that developers should not assume an anywise or pairwise nature of a DID for its method alone.
Hey folks, I noticed the way DIDs are generated/represented via use of the unique output of the initial DID Document and how delta-based CRDT op convergence was approached seem to be inspired by the way Sidetree does these things (a GH Issue in the Peer DID work even references Sidetree for the former). Do you think it would be OK to get a citation in the spec? Not a huge deal, just a nice-to-have if you all are amenable to it.
Trivial issue, but the Regex to match peer DIDs mentioned here. (Example 3). Will fail for Method 0 peers. It doesn't account for the multicodec value for the given public key format. To handle both, the regex:
^did:peer:[01](z)([1-9a-km-zA-HJ-NP-Z]{46, 47})$
appears to work.
Today the NSI begins with "1-F1220". This is 7 characters duplicated for every peer DID, and it means every instance is 80 characters long--not a disaster, but annoying in that they all cause ugly wrapping in commonly sized terminal windows.
The "1" at the beginning of the NSI versions the numeric generation algorithm. The F1220 says we are seeing a hex representation of the output of a sha256 algorithm. These are nice flexibilities of multibase and multihash, but it feels like we are paying an unreasonable cost for that flexibility. Our DID values aren't going to need all the power of multibase and multihash; only 1 or a very small handful of choices are ever going to be used. Flexibility for flexibility's sake is not beneficial: https://codecraft.co/2012/10/17/flexibility-is-no-virtue/. Also, it increases the learning curve for implementers and clutters up the spec with a couple extra paragraphs of explanation.
Can we simplify?
I would like to turn on the DCO bot, and to go back through history and add a Signed-off-by note to any commits that lack it. Do any of our contributors object? @kdenhartog @TelegramSam @csmarc @Oskar-van-Deventer @SvenHammann90 @devin-fisher @brentzundel @mavarley
Background:
It's not clear whether this spec will end up being sponsored in a formal way by any standards body or open source umbrella project--but it seems moderately likely that one or more of the W3C, DIF, and/or Hyperledger might endorse it officially.
If that happens, one of the issues that will arise is whether all contributors to a spec are officially aligned with this repo's Apache 2 license (which has always been here). Specifically, they will want to be sure that nothing in the spec is encumbered by copyright or patents in any way.
Github has a way to officially prove that, which is through the DCO bot. I can turn that on now, which will begin enforcement from this point forward. I can also modify the log message from any old commits to clarify that this was the case for them, too. But I don't want to modify old commit messages from any of you unless you are comfortable with me doing so.
For reference, this is common practice in Hyperledger, where I have done a lot of work, because it makes all the lawyers happy and it forces collaborating developers to be crisp about IP.
[from RWOT8-Barcelona Peer DID Method Specification Report]
Section 2.3 could be better structured with subsections (e.g. for keyfmtstring and idstring).
"The invitation is NOT encrypted, and it does NOT require the recipient (the invitee) to have special software that understands this protocol."
If an anywise DID is used, then can the public invitation be signed with a signing key from the DDO associated with that DID? And would such be useful?
Oskar
TNO - Techruption
[from RWOT8-Barcelona Peer DID Method Specification Report]
In sec 3.2 Messages (Messages are serialized and encrypted...), Indy HIPE message protocol is referenced - what extensions are required (multiplexed encryption) and why? The observation here is that pure JWE may be better for adoption, so understanding the need for extensions would be helpful.
When reading the document, I got a bit confused about the term “peer DID”.
-Can we explicitly state somewhere that the term is synonymous with “DID of the did:peer type”?
-Can we add a note somewhere that the term should not be confused with "pairwise DID”? After all, did:peer is not necessarily pairwise, pairwise DID are not necessarily did:peer.
-Can we add a note somewhere that the term should not be confused with “not publicly resolvable DID”? After all, also other DID methods may not be publicly resolvable, and maybe somebody builds a system to publicly resolve did:peer to aid key rollovers.
I really like the revised Introduction section. However, as I understand, anywise DIDs will be usually "normal" anchored DIDs on public ledgers. This is expressed more explicitly in Sec. 1.3. However, I think we could give a simple note about this to the reader already in the beginning of the Introduction.
"Generally, an anywise DID needs to be resolvable by strangers (i.e. publicly anchored DID). These strangers can use the DID to reference its subject (usually by resolving it on a public ledger) without establishing a relationship."
I suggest being specific in terms of how the state "delta" is communicated to peers, eg. json patch.
peer-did-method-spec/did-docs.html
Line 28 in b26c1bc
[from RWOT8-Barcelona Peer DID Method Specification Report]
Fix link in Sec 2.1 ("later") to Sec. 6. Grafting Peer DIDs Into Another DID Method Namespace.
Section 2.3
This is "1", denoting a format where idstring is the upper 16 bytes of an Ed25519 public key. This gives idstring a length of either 21 or 22 base58 characters. This spec may be updated to include other keyfmtchar variants for SecP256, Curve448, or similar. Such updates might change the length of idstring as well.
All good - I would put a placeholder reference to an 'Appendix' where other keyfmts will be defined (similar to what I've seen in JOSE specs). I believe that for now these definitions can live as an appendix to this document (and not its own broken out spec) , because there is only "1" :)
We need a paragraph of text around the use of initial state for communicating the first delta.
Helping readings of the spec understand by-example the power of the peer to peer architecture would help improve the readability of the spec. For example, I suggest the following changes (~line 92 of intro.html) that emphasizes its peer-to-peer sweet spot:
Because they avoid a dependence on a central source of truth, peer DIDs free themselves of the often-online requirement that typifies most other DID methods, and are thus well suited to use cases that need a decentralized peer-oriented architecture. Peer DIDs can be created and maintained for an entire lifecycle without any reliance on the internet, with no degradation of trust. They thus align closely with the ethos and the architectural mindset of the local-first and offline-first software movements.
I believe that we need to discuss explicitly the case where Alice’s private key to generate her did:peer with Bob got lost or stolen.
o Should Alice notify Bob, once she becomes aware of such breach?
o Should Bob notify Alice, if another person tries to establish a pairwise DID relationship with Bob, using Alice’s did:peer?
o Should Bob accept or reject the new pairwise DID relationship?
Note that this case would not exist in my interpretation of pairwise DID. So different interpretations would result in different implementations.
Oskar
TNO - Techruption
In the case that a peer DID and associated DID document get anchored to a ledger, how is a resolver supposed to know the method for resolving this DID? Typically the DID method is associated with a way to resolve a DID and I think if we anchor peer DIDs to multiple ledgers it could create a problem.
Assuming this were to occur, would the associated state change (history of the changes in the DID Doc) also be posted to the ledger?
If we consider this a valid use case (I think it's better to just create a new on ledger DID instead), what I would suggest is that we update the the identifier to be name spaced to the ledger and then peer. For example did:peer:NSI is transformed to did:sov:peer:NSI. This opens a can of worms though that we may not want to explore right now.
I would like to create an email distribution list (probably just a Google group) that we could use over the next month or two as this spec finalizes, to just make you aware of meaningful developments. I'd like to add each contributor to it, but for a number of you, I only have a github handle, not an email address. If you are willing to be on such a list, would you mind sending me a private email with your email address, at daniel dot hardman at evernym dot com?
The peer method spec includes a non-trivial authorization mechanism for defining what keys can be used when updating the DID Document. It seems to me that should mechanism should be work across DID methods. Checking a couple of other DID Methods, that does not seem to be the case, but wondered about the thoughts on that. I'm thinking that because of the underlying storage, perhaps that is not possible, since it would seem to be related to the update mechanism - e.g. messages in this case, but other techniques with other methods.
Related:
Other minor issues noted while reviewing:
Section 2.1
Furthermore, any direct or indirect anchoring of a peer DID to a specific blockchain is driven by circumstance and changeable at any time.
Do we need to provide guidance on this? (I think so...) and do we need an extension to the core DID spec to allow for DID linking/anchoring? (I'm not familiar enough with that spec...) For example, did:peer:1:347h3fnun9f2uh... has an entry in the attached DID Doc
"did_links": [ "did:sov:..." ] or the like?
Happy to discuss further as to why this would even be necessary.
In #82 , @Oskar-van-Deventer raised the question of the spec's permanent home. I have not been focused on that question, and I still don't know if it's an urgent question. But I wanted to open a ticket where the merits of finding one or more larger sponsors of the spec, and a place where the spec's github repo calls home, can be explored.
Some possible answers to this question include:
Section 3.2
I think we can safely remove the words around "However, nothing about this format is dependent on Indy. In particular, there are two implementations ..." and expand on "The format is as close as we could get to JWE conformance, but includes some extensions to handle multiplexed encryption"
The explanation around various implementations of the connection protocol is important (it originally concerned me, for example) but I think if the spec focuses on why this connection protocol is required for this DID method we are fine.
For example, "The connection-protocol extends JWEs and reuses an established method for INDY agents to establishing connections that are transmission agnostic - but the connection protocol is not INDY specific. It defines a message structure and sequence and error cases that aligns with the DID Peer requirements outlined below. Multiplexed encryption, for example, is a feature of the connection-protocol that is important for peer DID messaging for... (group support?.. dunno)."
Something like that?
I'm not very familiar with GDPR, and was wondering if this is true under the regulation:
Because only the parties to a given relationship know them, there is no concern about personal data and privacy regulations due to third party data controllers or processors.
Since the DID Document is likely being stored on a cloud agent, would this be consider a 3rd party data processor? Also, does it make a difference that the counterparty has a copy of the DID Document which contains a DID and other associated metadata. Are we certain that all data that is supposed to go within the DID Document is not considered PII?
I'm trying to clarify the TOFU section. I don't really understand the current wording and am trying to make it that I can.
I understand the out-of-band verification to confirm a connection. I send a code directly to the other party using another channel (say, visual, voice or email) and they confirm that code.
I also understand the use of verifiable credentials to confirm who received/processed the invitation. This handles the MITM scenario of someone other than the expected collaborator responding to the invitation.
However, there is one version of the hack that I can't figure out how to handle with the verifiable credential solution. Here is the scenario:
How can Alice be certain that the proof is from Bob and vice versa?
Assume (for now) we are using Indy for the verifiable credential exchange, and that Mallory is in-between all DIDComm messages between Alice and Bob.
I've tried to think about how to tie what Alice (assumes she) knows about Bob (basically, just a did:peer) with the proof. I'm thinking there might be some way to tie knowledge associated with the proof to the did:peer, but I don't know enough about the mechanics of the proof to determine that. Each thing I've come up with (signing or hashes) can be handled by Mallory reworking the response to use her did:peer DID with Alice.
Thoughts @kdenhartog @TelegramSam @dhh1128 @tplooker?
I would recommend you consider a Bech32 encoding over Base58 as it is both error-correcting & error-detecting. It has some other superior properties. We are using it for did:btcr as well. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
https://identity.foundation/sidetree/spec/
If the DID Document is being rendered in the JSON-LD representation variant, the implementer SHOULD add an
@baseentry to the document’s@context, and set the@basevalue to the id of the resolved DID. This ensures relative path values in the output DID Document are correctly projected into id-related strings by JSON-LD parsers.
Example: https://did.actor/bob/did.json
{
"@context": [
"https://www.w3.org/ns/did/v1",
{
"@base": "did:web:did.actor:bob"
}
],
"id": "did:web:did.actor:bob",
"publicKey": [
{
"id": "#z6MkkQBvgvqb6zGvS4cydworpUaRDzpszSFixq49ahbDeUTG",
"type": "Ed25519VerificationKey2018",
"controller": "",
"publicKeyBase58": "6wvt6gb9mSnTKZnGxNr1yP2RQRZ2aZ1NGp9DkRdCjFft"
}
]
}
This sentence is confusing (maybe due to a typo?):
"Nothing would prevent a user from publishing a peer DID and its associated DID document on some website, but such publication would be hard to discover, maintain as DID docs evolved, and integrate into interoperable applications."
We want it to be possible to pass deltas as parameters in web service calls; this won't work nicely unless we have the convention of encoding them in a URL-safe form.
In order to validate signatures and peer did identifiers, the documents must be transferred in a canonicalized format. If we just pass the structure inside a DIDComm message, different parsers will present different bytestreams.
Two options I see:
Thoughts
The current spec, unfortunately, states that it is a W3C Editor's Draft and links to a dead-end /TR/ URL for the current version.
This makes it look like the specification is standards-track at the W3C, which to my knowledge isn't correct.
We are referencing this work in the RWOT paper, A Rubric for Decentralization of DID Methods, which we will be presenting to the DID WG for consideration. It would be great if we could get the specification cleaned up before the January DID WG face-to-face.
Hi all,
I have been working on formal verification using the Tamarin prover for my RWOT topic paper and encountered a potential issue.
This specification states that man-in-the-middle attacks are excluded due to the way DIDs are generated from their (stored versions of) the DID documents. For this guarantee to hold, the inviter MUST verify for a DID + DID Doc they receive as an exchange request, that the DID was properly generated, using the algorithm from the (stored version of) the received DID Doc.
If this check is not performed, an attacker can insert a public key they control, while the DID would still look as if it belonged to the invitee. I describe the details of the attack in the long version of my RWOT topic paper, located at: https://github.com/SvenHammann90/SSI/blob/master/RWOT_9/Topic_Paper_RWOT.md
I believe the necessity for this check should be described in the doc, but I was not sure where it best fits (security considerations or the protocol itself?) and how to exactly phrase it, thus an issue and not a pull request.
Thank you for looking at this,
Sven
This issue tracks a deep discussion that first began on email.
Here's a link to the email thread: https://groups.google.com/forum/#!topic/peer-dids/mYmoXfI7be0
The goal of this issue is to get to alignment around requirements, the reasons for those requirements, and a good way to implement them.
Hi all,
I have encountered a peculiarity about peer DIDs in combination with the current version of DID Exchange, where I am unsure whether it poses a problem or not.
Suppose A and B have a connection, for which A uses peer DID (didA@B).
I believe that it is currently possible for an attacker who knows (didA@B) and its DID Doc to register (didA@B) with that DID Doc as its own peer DID with a third party C.
The reason is that, in an exchange request, the requester does not have to prove control of the secret key in the initial DID Doc's public key - at least, this is not the case in the current version of DID Exchange. I realize that this may be an issue of the DID Exchange spec, and might be addressed in the DID Comm WG or Aries WG (I'm not sure whether DID Exchange is part of the DID Comm WG)
However, I wonder if this is even a problem. Would a "re-use" of a peer DID between A and B in another context (involving a third party C) even pose any problem? Or are peer DIDs only "meaningful" between the two parties for which they were set up?
I do not see how such a re-use could directly hurt A or B, but it still allows the attacker to register a peer DID they do not control...
A discussion thread on this vulnerability was started in the W3C CCG. Here's a quick summary of it for background:
@SmithSamuelM and I have been discussing an issue that I wanted to bring to this group. It is a risk that Sam has described as the "anybody can ledgerize" problem: What is to prevent someone other than the owner of a DID from recording the initial version of a DID doc on a ledger, thus making public something that the owner intended to keep off ledger for the time being or permanently?
Even though this question is framed in terms of ledgers, it has direct application to non-ledger DID methods as well.
I believe that some DID methods allow anyone with write permission or willing to pay transaction fees to write a DID and its initial DID Doc to the shared source of truth. Since the DID doc just contains public keys, all the info in it might be known by someone other than the DID's owner -- another party in the list of controllers, for example, or even an adversary. Yes, the adversary possesses none of the private keys, and so cannot control the DID after registration--but the mere registration of someone else's data could, in and of itself, constitute mischief.
To guard against abuse, the correct behavior of a ledger is probably to require that the request to write the genesis version of the DID doc be signed by a key in the DID doc. Note that just signing the DID doc isn't enough, since the attacker could have captured the signature when he captured the DID doc content. Even better security would be to require that the DID value be derived from a key in the DID doc, and that the initial write request use that key as well. Perhaps this protection against abuse needs to be a rubric? Or perhaps it is more fundamental, and needs to be a requirement of all DID methods, period?
Now I'd like to reason about how this applies to peer DIDs. Here's how it could play out there: Alice's agent 1 creates a DID doc for a relationship with Bob, naming keys for agent 2 and agent 3 as also authorized. Then Alice's agent 2 (which may have been hacked without Alice realizing it) can take that DID doc and send it to Carol, using the agent 2 key to sign. The rogue agent thus "registers" the DID doc in a way and with a party that the DID owner did not intend. This is basically the "anybody can ledgerize" attack.
Originally, the peer DID spec required the peer DID value to be derived from "the public key". However, at IIW last spring, Christian Lundkvist convinced me that the did should derive from a hash of the genesis version of the DID Doc instead. Since that includes one or more public keys, it has much the same protections. But it doesn't have a protection against the abuse case I described in the preceding paragraph.
At first glance, there seemed to be 3 possible answers:
Start the DID Doc with one public key; this is "the public key" from which the DID value derives, granting authority to all others. Require that the other 3 keys be added in subsequent operation(s).
Allow the DID Doc to be created with multiple keys, but make one of the keys special (e.g., the first key, or the key tagged as "prime" or some such); this is the one that must authorize creation.
Technique 1 might seem better from the perspective of self-certification purity, but it has a different cybersecurity problem, which is that such a strategy requires that you operate without checks and balances, and without backups, for some period of time early in the lifespan of every DID. We therefore discarded it; we wanted to be able to say, even in the genesis state, that a given DID is guarded by M-of-N signature policies, for example.
Right now the peer DID spec takes a weakened form of approach 2. It simply requires that the genesis DID doc be associated with (not necessarily signed by) one of the keys in its genesis state. Besides direct signing, "associated with" could mean that the genesis DID doc is streamed over DIDComm channels that authencrypt with one of the keys in question.
There is option 3:
This eliminates the "anybody can ledgerize" risk, but it may be unacceptably inconvenient. I might create several keys that I store in vaults, offline, and that I never want to pull out when I'm creating new relationships--yet I might want to name those keys in the genesis versions of my pairwise DID Docs.
@SmithSamuelM suggested my current preferred option, which is to use pre-rotation. Basically we start a peer DID with only 1 key, and then we immediately create a delta that adds the other keys, before we even share the DID Doc at all. This is easily done and satisfies the convenience and strong security requirements. Its only drawback is that we need to modify the connection protocol (Aries RFC 0023) so it's possible to send a delta along with the initial version of a DID Doc that's exchanged when building a connection.
Several links to Indy HIPEs should be replaced by Aries RFC links. Also, the protocol name for establishing connections is now called the "DID Exchange" protocol, not the "connection" protocol.
It's a little odd that DIDs are derived from a DID doc which is supposed to contain the DID in the first place. What is wrong with hashing the public key?
[from RWOT8-Barcelona Peer DID Method Specification Report]
In 1.2 Groups section, it should be made clear that if Alice and Bob are already connected (through peer DIDs), but wish to add another party, they should first create new peer DIDs with one another then invite Carol to that group.
Removing participants from a Group is basically recreating the group without the person who is 'removed'.
Oskar D created the following doc to describe a concern: https://docs.google.com/document/d/1nnzAvF0tJgHtDut8GqcC6Fb_hXibV9JVyQbQ7suul60/edit
[from RWOT8-Barcelona Peer DID Method Specification Report]
In Sec. 2.3 Namespace Specific Identifier, we understand the need for keyfmtchar, but it needs a definition, and an example of when to use it (i.e., when to make a "2") would be helpful.
This issue is related to #2.
I found the definition of key_admin, se_admin, rule_admin a bit static as they are related with which parts of the doc can modify.
My proposal is to add paths in the authorization object to be more flexible and more self defined:
authorization: {
profiles: [
{
key: '#1234',
roles: ['edge']
}
],
rules: [
{
grant: ['register', 'key_admin', 'se_admin', 'rule_admin'],
when: { id: '#1234' }
},
{
grant: ['authcrypt', 'plaintext', 'sign'],
when: { roles: 'edge' }
},
{
grant: ['route', 'authcrypt'],
when: { roles: 'cloud' }
}
],
paths: [
{
grant: ['/authorization/paths'],
when: {
any: [
{ roles: 'per_admin' },
{ id: '#1234' }
]
}
},
{
grant: ['/publicKey', '/authorization/profiles', '/authentication'],
when: {
any: [
{ roles: 'key_admin' }
]
}
},
{
grant: ['/authorization/rules'],
when: { roles: 'rule_admin' }
},
{
grant: ['/services'],
when: { roles: 'se_admin' }
}
]
}This will mean key '#1234' have this grants:
Set {
'register',
'key_admin',
'se_admin',
'rule_admin',
'authcrypt',
'plaintext',
'sign'
}And permission to modify this paths of the doc:
Set {
'/authorization/paths',
'/publicKey',
'/authorization/profiles',
'/authentication',
'/authorization/rules',
'/services'
}And this can be useful if some key is allowed only to modify /services/0 for example
What do you think?
Regards
I would love to see a list of implementations, and a conformance test suite for did peer, along with test vectors.
I'm happy to help maintain one of the implementations assuming I can see at least 1 other one :)
Here are some (possible) typos
There is
"publicKey": "ddid:peer:qQk1twjzCmEMgLDRN ..."
I assume the double d in "ddid" is a type
There is a hash "#" in
"publicKey": "ddid:peer:qQk1twjzCmEMgLDRNmo7oS#1"
is that hash a typo, or a feature of DDO?
Why is the DID
"id": "did:peer:qQk1twjzCmEMgLDRNmo7oS"
different from
"for": "did:peer:rjHiqAzCbsNYhMZDTUASHg"
What is the semantics of each DID? Or is this just a typo?
Section 1.1.1 introduces term "did value" without defining it.
"DID values are securely random"
There are a number of areas in the specification that could benefit from the use of multibase, multihash, and multicodec:
https://tools.ietf.org/html/draft-multiformats-multibase-01
https://tools.ietf.org/html/draft-multiformats-multihash-00
https://github.com/multiformats/multicodec#multicodec
The suggestion here is to do one or more of the following:
Veres One already uses these formats for the expression of these data types, including ed25519 public keys. Sovrin, and a few other ledgers, use ed25519 public keys. Bitcoin and Ethereum use secp256k1. If we can get alignment on how to express public keys, it becomes possible to anchor and use public keys in an interoperable way across blockchains.
For example, in a did:peer document, if you had this as a encoding for a public key:
did:peer:11-z279wDK5GK3nSaqQmnHJxG6LRQ7CuZpvWpEcty2qfT6Cjz9g
You could easily also use it on Veres One (note that nothing changes with the key encoding for the ed25519 public key at the end... it's literally just a search and replace):
did:v1:nym:z279wDK5GK3nSaqQmnHJxG6LRQ7CuZpvWpEcty2qfT6Cjz9g
Same with Bitcoin and Ethereum, you could, in a did:peer DID Document, express a secp256k1 key like so:
did:peer:11-z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER
and then lift and use that in BTCR or an Ethereum-based transaction, like so:
did:btcr:z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER
did:ethr:z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER
I'm not sure if this is accurate, but it seems like a simple JWS based section would clear this up...
Show people exactly how to handle the delta creation.
If JWS is not used... this is even less clear...
[from RWOT8-Barcelona Peer DID Method Specification Report]
The language of the abstract is "marketing speak". We would suggest changing it to state just the intent.
"The method is cheap, fast, scalable, and secure" -> "The method is intended to be cheap, fast, scalable, and secure".
In which scenarios will the code in comparePeerDIDs be used? It compares only prefix. Is it meant to be used in cases where it needs to be checked that numalgo or encalgo of 2 DIDs are compatible?
Nitpick: The example takes first 12 characters which will give incorrect results when numalgo or encalgo take more than 1 digit. Better to use regex.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.