` with the tripsig. Display the tripkey right where you display tripcodes now. 77 | 78 | Call `render_tripkey(el)` in your board JavaScript for each tripkey on the page, so that when the user hovers they'll see the friendlier emoji version of the key along with the `$input` and `$tripsig` should they wish to verify the post on their own computer. 79 | 80 | ![](https://raw.githubusercontent.com/ctrlcctrlv/tripkeys/master/doc/UI_hover_example.png) 81 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![](https://raw.githubusercontent.com/ctrlcctrlv/tripkeys/master/doc/logo.svg) 2 | 3 | This repository contains: 4 | 5 | * a description of the tripkey system, a new type of identification for anonymous BBS's ([`doc/OVERVIEW.md`](https://github.com/ctrlcctrlv/tripkeys/blob/master/doc/OVERVIEW.md)) 6 | * an implementation in PHP (verifying) and JavaScript (signing/UI) of tripkeys (not yet uploaded) 7 | * a patch for implementation of the same in Vichan; (`vichan_tripkeys.patch`) (TODO) 8 | * a detailed explanation of the patch so you can implement it in your own imageboard software, free (meguca, fatchan, 314chan, etc.) or proprietary (420chan, etc.); ([`doc/PATCH_HOWTO.md`](https://github.com/ctrlcctrlv/tripkeys/blob/master/doc/PATCH_HOWTO.md)) 9 | * a historical overview of tripcodes (below). 10 | 11 | This is simply a formalization and standardization of my video of 27 November 2019, [“A tutorial for QAnon, or, how to use Bitcoin addresses to verify your messages on any website”](https://www.youtube.com/watch?v=c8EjDKEeusM). To both further embarass QAnon, and advance the state of the art of imageboards, I dedicate this work to open source. 12 | 13 | ## Tripcodes 14 | 15 | A _tripcode_ is, on an anonymous BBS, such as 4chan, a string of letters and numbers that appears next to a user's name when they post. There are different ways to generate this string of letters and numbers, and the generation method has subtle impacts on both users and administrators. 16 | 17 | I will briefly talk about the main methods of tripcode generation, and then make the case for why we need a new one, which I call a _tripkey_. 18 | 19 | My _tripkey_ method takes the power out of the hands of server owners and into the hands of users, allowing users to move their identity between imageboards freely. 20 | 21 | ### FOX's 2channel-style (!...) 22 | 23 | The most widely used, even today, method of tripcode generation is based on the following script, first written by an early programmer for 2channel, 🟊FOX (Yoshihiro Nakao, 中尾嘉宏). 24 | 25 | ```perl 26 | $tripkey = "#istrip"; # トリップキー文字列（# 付き） 27 | $tripkey = substr $tripkey, 1; 28 | $salt = substr $tripkey . "H.", 1, 2; 29 | $salt =~ s/[^\.-z]/\./g; 30 | $salt =~ tr/:;<=>?@[\\]^_`/A-Ga-f/; 31 | $trip = crypt $tripkey, $salt; 32 | $trip = substr $trip, -10; 33 | $trip = "◆" . $trip; 34 | print $trip, "\n"; 35 | ``` 36 | 37 | The comment means, in English, "tripcode password (with #)". 38 | 39 | A version of this script with many more comments and which accepts input from STDIN can be found in the file [`doc/2ch_tripcode_annotated.pl`](https://github.com/ctrlcctrlv/tripkeys/blob/master/doc/2ch_tripcode_annotated.pl). 40 | 41 | Nakao's code is ≈20 years old, and modern hardware can easily break its tripcodes. It suffers from further deficits: only the first eight characters of the tripcode matter, [because that's all `crypt` considered in Perl](https://perldoc.perl.org/functions/crypt). 42 | 43 | ``` 44 | Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/tripkeys 45 | $ ./doc/2ch_tripcode_annotated.pl 46 | #istrip 47 | Info: salt is st 48 | Tripcode: ◆/WG5qp963c 49 | 50 | Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/tripkeys 51 | $ ./doc/2ch_tripcode_annotated.pl 52 | #:_` 53 | Info: salt is ef 54 | Tripcode: ◆rZgPfaS/mo 55 | 56 | Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/tripkeys 57 | $ ./doc/2ch_tripcode_annotated.pl 58 | #wakuwaku 59 | Info: salt is ak 60 | Tripcode: ◆tSdCM0v21w 61 | 62 | Fred@DESKTOP-CBDJO68 MSYS ~/Workspace/tripkeys 63 | $ ./doc/2ch_tripcode_annotated.pl 64 | #wakuwaku`` 65 | Info: salt is ak 66 | Warning: Dropped ``, these bytes did not count! 67 | Tripcode: ◆tSdCM0v21w 68 | ``` 69 | 70 | On a modern GPU found in any regular consumer-grade PC, a 2channel-style tripcode can be broken in days. Even Ron Watkins of 8chan admits this. 71 | 72 | ### 8chan-style "secure tripcodes" 73 | 74 | While not originated on 8chan, so-called "secure tripcodes" became most famous there due to their use by the LARPer QAnon. A "secure tripcode" is made "secure" (uncrackable) by making the following changes: 75 | 76 | * instead of DES, use SHA1; 77 | * use a secret server-side salt instead of deriving the salt from the key; 78 | * rotate the salt occasionally to prevent leaks. 79 | 80 | The function which generated these on 8kun can be seen in [`inc/functions.php:generate_tripcode`](https://github.com/ctrlcctrlv/infinity/blob/master/inc/functions.php#L2755). 81 | 82 | However, this function still used DES. According to Watkins, [SHA1 is now in use](https://twitter.com/CodeMonkeyZ/status/1298630319759712256). Without Watkins telling us that, though, we'd have no way to know. This is because we do not know the salt, so we can not verify that the algorithm works how they say it works. Even if we know our password, we can't prove that it equals any particular tripcode on 8kun without either (a) hacking 8kun and getting the salt from the server or (b) using 8kun. 83 | 84 | In that original 8chan source code we see the lines: 85 | 86 | ```php 87 | // Lines 2776 to 2780: 88 | if ($secure) { 89 | if (isset($config['custom_tripcode']["##{$trip}"])) 90 | $trip = $config['custom_tripcode']["##{$trip}"]; 91 | else 92 | $trip = '!!' . substr(crypt($trip, str_replace('+', '.', '_..A.' . substr(base64_encode(sha1($trip . $config['secure_trip_salt'], true)), 0, 4))), -10); 93 | } // ... 94 | ``` 95 | 96 | We can see that the server admin can put whatever tripcode they want in the `$config[custom_tripcode]` hashmap. So, so-called "secure tripcodes" are only "secure" if we trust the server admins. If they are dishonest, they can put any tripcode on any post, or make any password equal any tripcode. 97 | 98 | This means, of course, that they can hijack any tripcode user's identity, including QAnon's. 99 | 100 | ## There is a better way 101 | 102 | And you are looking at it. 103 | 104 | See [`doc/OVERVIEW.md`](https://github.com/ctrlcctrlv/tripkeys/blob/master/doc/OVERVIEW.md) for an overview of my proposed system. 105 | 106 | ## Comparison to the state of the art 107 | 108 | The only thing even remotely similar to this project is the PGP ability had by [Infinity Next](https://github.com/infinity-next/infinity-next) (infinity-next/infinity-next, AGPL3). 109 | 110 | However, that ability is inferior in quite a few ways: 111 | 112 | * it requires the server to remember keys, and it *uses the system keyring*. I think this is a possible DoS vector because users can fill up the keyring and it never gets pruned. 113 | * it is not possible for users to post just with a password, there's no password-based key derivation. 114 | -------------------------------------------------------------------------------- /doc/OVERVIEW.md: -------------------------------------------------------------------------------- 1 | # The tripkey system 2 | 3 | The tripkey system has three main elements exposed to the user: 4 | 5 | * the _trippass_, the password the user actually enters; (example: `###IAmASecretAgentMan`) 6 | * the _tripkey_, the equal to the hash in the traditional tripcode system; (example: `!!!r9c6ksuawj5fzjle5gx9rv0h40emk322uw6tjs`) 7 | * the _tripsig_, a signature which is different in every post which more technical users can use outside any one anonymous BBS to verify a post. 8 | 9 | And two hidden internal elements which advanced users can take advantage of: 10 | 11 | * the _tripsecret_, created from the _trippass_ via key-derivation. If a user does not wish to use our key derivation, they can use any of the multiple ways of creating Bitcoin private keys and create a public/private key combo themselves and create tripsigs themselves. 12 | * the _tripinput_, which is the actual input plaintext transformed to prevent replay attacks. 13 | 14 | This is in every way a superior system as it gives the user these guarantees: 15 | 16 | * if you choose a secure password, your tripkey will not be broken unless Bitcoin signatures (SHA256) are broken; 17 | * your tripkey is for all intents and purposes equal to a tripcode. Normal Anons don't need to learn anything. If the tripkey matches on the screen, the post is by the same person. 18 | * you can out the server admin if they try pass off a post as being signed with a certain tripkey when it was not; 19 | * you can sign your posts on the client side, even outside of the browser! 20 | 21 | Users can give as much or as little access to the private key as they choose. If they trust the server admin, they can sign their posts right in their browser completely transparently to them. 22 | 23 | Furthermore, we get to rely on Bitcoin's strong cryptography, without giving a rat's ass about the blockchain. Our code doesn't know that a blockchain even exists. We're using the addresses and the signatures, absolutely no Bitcoin needs to be owned to sign or verify a tripsig was created by a tripkey! 24 | 25 | Here are the two example flows: 26 | 27 | ## Non-technical anonymous user flow 28 | 29 | Anonymous enters their name followed by their tripkey, exactly as they would a regular tripcode. So, if they are currently posting by putting in the name field either `SecretSpy#IAmASecretAgentMan` or `SecretSpy##IAmASecretAgentMan`, they would now post as `SecretSpy###IAmASecretAgentMan`. (Note the number of `#`'s used.) 30 | 31 | That's it. We do all of the following behind the scenes: 32 | 33 | * The browser uses the `tripkeyPBKDF`, a very simple, standardized password-based key derivation function explained below, to go from `IAmASecretAgentMan` to a private key containing the right number of bytes to become a Bitcoin private key. For `IAmASecretAgentMan`, `tripkeyPBKDF` yields the bytes `31:e7:6c:bc:7d:3e:80:95:f0:8b:b9:77:18:77:ca:3d:75:95:21:e5:89:8e:a6:18:ed:50:15:48:06:65:f3:a4`; these are exactly enough bytes.* 34 | * We use the output of `tripkeyPBKDF` as our private key. We can convert even convert the hex to wallet input format: `KxtiajhLq5EUdSUHMpWjd5iUS3o5X3x7psC7uJyY897rfKUeaQZU`.† 35 | * With our private key, we now can get the bech32 address (public key): `bc1qav0jadp87tr0thmkav4gfq2hudfqrdyt07dlk4`. We almost have the user's tripkey!‡ 36 | * Simply replace the beginning `bc1q`, which is constant, with `!!!`. Tripkey: `!!!av0jadp87tr0thmkav4gfq2hudfqrdyt07dlk4`. 37 | 38 | When the user presses «Post», all of this happens, and their post will show up under `SecretSpy !!!av0jadp87tr0thmkav4gfq2hudfqrdyt07dlk4`! And, furthermore, other users who may or may not trust your server can verify this key: they can copy the generated tripsig, e.g. `ICpkJ3fZRWp87zPZ7gOpw/4kvK4Ew+ihemsZxHMLZPM0sdZu/82GEHCzaNqs4Qmiu+idLG0ypKydVKEUQz6NQOg=`, and the input JSON (see § tripinput) and use the command line tripsig verification tool to know that nothing was tampered with, that this tripkey really did produce this message! 39 | 40 | ---- 41 | 42 | 43 | Below I'll show simple ways you can verify every step right in your browser. Of course, my code does all of this for you. But just in case you want third party verification that what we're doing is secure and I haven't inserted any poison pill: this is pure Bitcoin/scrypt. 44 | 45 | * My `tripkeyPBKDF` function is so simple we can recreate its behavior with [the generic `scrypt-js` demo](https://ricmoo.github.io/scrypt-js/) (ricmoo/scrypt-js, MIT). For password, `IAmASecretAgentMan`. For salt, `naMtnegAterceSAmAI` (reversed password). For **Nlog2**, 12. **r**, 8. **p**, 1. dkLen, **32**. Output will include ``Generated: 31e76cbc7d3e8095f08bb9771877ca3d759521e5898ea618ed5015480665f3a4``. Make sure both password and salt are set to `UTF-8 (NFKC)`. 46 | 47 | † The famous `bitaddress` (pointbiz/bitaddress.org, MIT) can do this. Press «Wallet Details», then paste the hex: `31e76cbc7d3e8095f08bb9771877ca3d759521e5898ea618ed5015480665f3a4` in the «Enter Private Key» field. Press «View Details», then scroll down and copy «Private Key WIF Compressed». 48 | 49 | ‡ We can use [`segwitaddress`](https://segwitaddress.org/bech32/) (coinables/segwitaddress, MIT), which internally uses `bitcoinjs-lib`'s bitcoin.ECLib for this purpose (bitcoinjs/bitcoinjs-lib, MIT). Scroll down to § Details, and in the «WIF Private Key» field, paste `KxtiajhLq5EUdSUHMpWjd5iUS3o5X3x7psC7uJyY897rfKUeaQZU`. Press «Show Details», and copy the «Address». 50 | 51 | 52 | ### `tripkeyPBKDF` 53 | 54 | `tripkeyPBKDF` is both a password-based key derivation function and a password-based salt derivation function. It uses scrypt internally, upon which Litecoin among other cryptographic coins relies. `tripkeyPBKDF` is _optional_, more advanced users may come up with their private keys any way they choose. 55 | 56 | `tripkeyPBKDF` v0, as mentioned in the footnote in the above section, uses these scrypt parameters: 57 | 58 | | Nlog2 | r | p | dkLen | 59 | |-------|---|---|-------| 60 | | 12 | 8 | 1 | 32 | 61 | 62 | The only thing you might hesitate about is how we're getting our salt. We simply _reverse_ the password. So, given `IAmASecretAgentMan`, our salt will be `naMtnegAterceSAmAI`. I believe this is secure for many reasons. For one thing, in scrypt, this does not need to be a secret salt. It just needs to be different for every invocation to prevent rainbow table attacks. Clearly, just reversing the password is good enough unless someone can prove otherwise. 63 | 64 | ## Making the key unspendable 65 | 66 | One "problem" that some might complain about is that we've inadvertantly made it so that users can "tip" tripcode users with Bitcoin. I personally do not see this as a problem and in my implementation have done nothing to "fix" it. However, if this really concerns you, there's a simple solution: XOR the public key with a [nothing-up-my-sleeve number](https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number). Yes, users can XOR them again, because for tripkeys to be verifiable you must disclose the XOR value, but they won't simply be able to replace `!!!` with `bc1q`. 67 | 68 | If you are very paranoid about stopping technical users who will go through the trouble of XOR'ing from exchanging tips, perhaps this system is not for you. I am open to other ideas for making keys unspendable, but really, do not see this as very important. 69 | 70 | Remember indeed that very popular users, for whom this may be a concern, but who do not want to collect any money, can use Bitcoin Script to make a valid address unspendable by making all inputs `OP_RETURN`; they can also simply send any coins they receive back. 71 | 72 | In future, we may want to slightly modify the constants for tripkey generation so they're just different enough from Bitcoin address generation that addressess won't be spendable. For example, classic Litecoin addresses, which begin with `L`, cannot be used on the Bitcoin network just by changing `L` to `1`. 73 | 74 | ## Technical anonymous user flow 75 | 76 | Let's say that a hypothetical nerdier user wants to take advantage of some of the benefits of being able to use any Bitcoin private key. Instead of posting as `SecretSpy###IAmASecretAgentMan`, they instead will post with their name fields like this: 77 | 78 | ```plain 79 | SecretSpy!!!av0jadp87tr0thmkav4gfq2hudfqrdyt07dlk4!!!H169+GZtHROqos8hONufnLfE6TPOHZXxVgx/4j07zb2e4opThngxx6VkY4yX2bHHg/DgedIiGVAHERW2KH87bjs= 80 | ``` 81 | 82 | And your server will verify that the signature ``H169+GZtHROqos8hONufnLfE6TPOHZXxVgx/4j07zb2e4opThngxx6VkY4yX2bHHg/DgedIiGVAHERW2KH87bjs=`` works for their message, and allow the post through. 83 | 84 | Now, of course, we need to prevent replay attacks! If this is all there is to it, users may impersonate tripkey users by posting their messages. They won't be able to post any message the tripkey user didn't write, but with a sufficiently large corpus could easily troll tripkey users by playing their posts back at them. 85 | 86 | So let's do that by changing the plaintext. Introducing: tripkey input JSON, _tripinput_. 87 | 88 | ### Tripinput 89 | 90 | For simplicity, **must** be UTF-8. 91 | 92 | Note: Real implementations must remove all unnecessary whitespace, but ignore all whitespace in ``! Otherwise valid signatures will not match. All keys and values must be strings! 93 | 94 | Example: 95 | 96 | ```json 97 | { 98 | "version": "0", 99 | "head": { 100 | "site": "org.420chan", 101 | "board": "a", 102 | "window": "1601543100", 103 | "name": "SecretSpy" 104 | }, 105 | "files": [ 106 | "29f5278bca09997ec2603675f45c4e5c90816a212ecdd67ffc4d2677a961c4e7" 107 | ], 108 | "body": "心が死ぬよ自分のためらいが引き金になるよ 109 | 「助けて」君へと 110 | 「信じて」君から漏れた声に揺れる 111 | 112 | 泣きたくないこれ以上会いたくない 113 | 燃える愛しさが交差した 114 | 会いにきて泣きたくて追いかけて 115 | 誰にもとめられない 116 | 117 | これは未来? それとも夢? 答えはどこだろう 118 | これが今を試す扉壊すの? 開けるの? どうしよう? 119 | 120 | Everything will be decided by the rules" 121 | } 122 | ``` 123 | 124 | This JSON will also be generated by the browser when users post using the simple password-based system, just without being imposed on users who don't care to find out how the system works. 125 | 126 | The only thing that might be confusing is the _window_, everything else is self-explanatory. The _window_ is just this formula, where _t_ is the current seconds since 1970: 127 | 128 | ```c 129 | t-(t%(60*5)) 130 | ``` 131 | 132 | So, every five minutes, this gets invalidated. In the example, your server **must** check the following: 133 | 134 | * user requested name SecretSpy; 135 | * our constant site name is org.420chan; 136 | * board being posted on is /a/; 137 | * the current Unix epoch time is within five minutes of 1601543100; 138 | * the SHA256 hashes of all uploaded files match. 139 | 140 | If _any_ condition is not true, the post **must** be rejected. 141 | 142 | Furthermore, you **must** store approved signatures in a separate table for at least five minutes, and not allow signatures to be double posted. You **must** check that the current signature is not already known to you. 143 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | 204 | -------------------------------------------------------------------------------- /doc/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 339 | --------------------------------------------------------------------------------