add base uris

README.md

 # Well-known URI
 
+https://en.wikipedia.org/wiki/Well-known_URI
 
-
-## Getting started
-
-To make it easy for you to get started with GitLab, here's a list of recommended next steps.
-
-Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
-
-## Add your files
-
-- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
-
-```
-cd existing_repo
-git remote add origin https://git.iiens.net/arise/well-known.git
-git branch -M main
-git push -uf origin main
-```
-
-## Integrate with your tools
-
-- [ ] [Set up project integrations](https://git.iiens.net/arise/well-known/-/settings/integrations)
-
-## Collaborate with your team
-
-- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
-- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
-- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
-
-## Test and Deploy
-
-Use the built-in continuous integration in GitLab.
-
-- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)
-- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
-
-***
-
-# Editing this README
-
-When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
-
-## Suggestions for a good README
-
-Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
-
-## Name
-Choose a self-explaining name for your project.
-
-## Description
-Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
-
-## Badges
-On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
-
-## Visuals
-Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
-
-## Installation
-Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
-
-## Usage
-Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
-
-## Support
-Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
-
-## Roadmap
-If you have ideas for releases in the future, it is a good idea to list them in the README.
-
-## Contributing
-State if you are open to contributions and what your requirements are for accepting them.
-
-For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
-
-You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
-
-## Authors and acknowledgment
-Show your appreciation to those who have contributed to the project.
-
-## License
-For open source projects, say how it is licensed.
-
-## Project status
-If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
+> A **well-known URI** is a [Uniform Resource Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) for [URL](https://en.wikipedia.org/wiki/URL) path prefixes that start with `/.well-known/`. They are implemented in webservers so that requests to the servers for **well-known services** or information are available at URLs consistent **well-known locations** across servers. 

uris/dnt

+{
+  "tracking": "N"
+}

uris/dnt-policy.txt

+Do Not Track Compliance Policy 
+
+Version 1.0
+
+This domain complies with user opt-outs from tracking via the "Do Not Track"
+or "DNT" header  [http://www.w3.org/TR/tracking-dnt/].  This file will always
+be posted via HTTPS at https://www.iiens.net/.well-known/dnt-policy.txt
+to indicate this fact.
+
+SCOPE
+
+This policy document allows an operator of a Fully Qualified Domain Name
+("domain") to declare that it respects Do Not Track as a meaningful privacy
+opt-out of tracking, so that privacy-protecting software can better determine
+whether to block or anonymize communications with this domain.  This policy is
+intended first and foremost to be posted on domains that publish ads, widgets,
+images, scripts and other third-party embedded hypertext (for instance on
+widgets.example.com), but it can be posted on any domain, including those users
+visit directly (such as www.example.com). The policy may be applied to some
+domains used by a company, site, or service, and not to others.  Do Not Track
+may be sent by any client that uses the HTTP protocol, including websites,
+mobile apps, and smart devices like TVs. Do Not Track also works with all
+protocols able to read HTTP headers, including SPDY.
+
+NOTE: This policy contains both Requirements and Exceptions. Where possible
+terms are defined in the text, but a few additional definitions are included
+at the end.
+
+REQUIREMENTS
+
+When this domain receives Web requests from a user who enables DNT by actively
+choosing an opt-out setting in their browser or by installing software that is
+primarily designed to protect privacy ("DNT User"), we will take the following
+measures with respect to those users' data, subject to the Exceptions, also
+listed below:  
+
+1. END USER IDENTIFIERS:         
+
+  a. If a DNT User has logged in to our service, all user identifiers, such as
+     unique or nearly unique cookies, "supercookies" and fingerprints are 
+     discarded as soon as the HTTP(S) response is issued.                                    
+
+     Data structures which associate user identifiers with accounts may be
+     employed to recognize logged in users per Exception 4 below, but may not
+     be associated with records of the user's activities unless otherwise
+     excepted.
+
+  b. If a DNT User is not logged in to our service, we will take steps to ensure 
+     that no user identifiers are transmitted to us at all.         
+
+2. LOG RETENTION: 
+
+  a. Logs with DNT Users' identifiers removed (but including IP addresses and
+     User Agent strings) may be retained for a period of 10 days or less,
+     unless an Exception (below) applies. This period of time balances privacy
+     concerns with the need to ensure that log processing systems have time to
+     operate; that operations engineers have time to monitor and fix technical
+     and performance problems; and that security and data aggregation systems
+     have time to operate.
+
+  b. These logs will not be used for any other purposes.         
+
+3. OTHER DOMAINS: 
+
+  a. If this domain transfers identifiable user data about DNT Users to
+     contractors, affiliates or other parties, or embeds from or posts data to
+     other domains, we will either:         
+
+  b. ensure that the operators of those domains abide by this policy overall
+     by posting it at /.well-known/dnt-policy.txt via HTTPS on the domains in
+     question,
+
+    OR
+
+     ensure that the recipient's policies and practices require the recipient
+     to respect the policy for our DNT Users' data.
+
+    OR  
+
+     obtain a contractual commitment from the recipient to respect this policy
+     for our DNT Users' data.
+
+    NOTE: if an “Other Domain” does not receive identifiable user information
+    from the domain because such information has been removed, because the
+    Other Domain does not log that information, or for some other reason, these
+    requirements do not apply.
+
+  c. "Identifiable" means any records which are not Anonymized or otherwise
+     covered by the Exceptions below.
+
+4. PERIODIC REASSERTION OF COMPLIANCE: 
+
+  At least once every 12 months, we will take reasonable steps commensurate
+  with the size of our organization and the nature of our service to confirm
+  our ongoing compliance with this document, and we will publicly reassert our
+  compliance.
+
+5. USER NOTIFICATION: 
+
+  a. If we are required by law to retain or disclose user identifiers, we will
+     attempt to provide the users with notice (unless we are prohibited or it
+     would be futile) that a request for their information has been made in
+     order to give the users an opportunity to object to the retention or
+     disclosure.
+
+  b. We will attempt to provide this notice by email, if the users have given
+     us an email address, and by postal mail if the users have provided a
+     postal address.                                   
+
+  c. If the users do not challenge the disclosure request, we may be legally
+     required to turn over their information.
+
+  d. We may delay notice if we, in good faith, believe that an emergency
+     involving danger of death or serious physical injury to any person
+     requires disclosure without delay of information relating to the
+     emergency.
+
+EXCEPTIONS
+
+Data from DNT Users collected by this domain may be logged or retained only in
+the following specific situations:
+
+1. CONSENT / "OPT BACK IN"         
+
+  a. DNT Users are opting out from tracking across the Web.  It is possible
+     that for some feature or functionality, we will need to ask a DNT User to
+     "opt back in" to be tracked by us across the entire Web.                                    
+
+  b. If we do that, we will take reasonable steps to verify that the users who
+     select this option have genuinely intended to opt back in to tracking.
+     One way to do this is by performing scientifically reasonable user
+     studies with a representative sample of our users, but smaller
+     organizations can satisfy this requirement by other means.         
+
+  c. Where we believe that we have opt back in consent, our server will
+     send a tracking value status header "Tk: C" as described in section 6.2
+     of the W3C Tracking Preference Expression draft:
+
+     http://www.w3.org/TR/tracking-dnt/#tracking-status-value
+
+2. TRANSACTIONS         
+
+   If a DNT User actively and knowingly enters a transaction with our
+   services (for instance, clicking on a clearly-labeled advertisement,
+   posting content to a widget, or purchasing an item), we will retain
+   necessary data for as long as required to perform the transaction. This
+   may for example include keeping auditing information for clicks on
+   advertising links; keeping a copy of posted content and the name of the
+   posting user; keeping server-side session IDs to recognize logged in
+   users; or keeping a copy of the physical address to which a purchased
+   item will be shipped.  By their nature, some transactions will require data
+   to be retained indefinitely.
+
+3. TECHNICAL AND SECURITY LOGGING:                   
+
+  a. If, during the processing of the initial request (for unique identifiers)
+     or during the subsequent 10 days (for IP addresses and User Agent strings),
+     we obtain specific information that causes our employees or systems to
+     believe that a request is, or is likely to be, part of a security attack,
+     spam submission, or fraudulent transaction, then logs of those requests 
+     are not subject to this policy.                                   
+
+  b. If we encounter technical problems with our site, then, in rare
+     circumstances, we may retain logs for longer than 10 days, if that is
+     necessary to diagnose and fix those problems, but this practice will not be
+     routinized and we will strive to delete such logs as soon as possible.         
+
+4. AGGREGATION:
+
+  a. We may retain and share anonymized datasets, such as aggregate records of
+     readership patterns; statistical models of user behavior; graphs of system
+     variables; data structures to count active users on monthly or yearly
+     bases; database tables mapping authentication cookies to logged in
+     accounts; non-unique data structures constructed within browsers for tasks
+     such as ad frequency capping or conversion tracking; or logs with truncated
+     and/or encrypted IP addresses and simplified User Agent strings.
+
+  b. "Anonymized" means we have conducted risk mitigation to ensure
+     that the dataset, plus any additional information that is in our
+     possession or likely to be available to us, does not allow the
+     reconstruction of reading habits, online or offline activity of groups of
+     fewer than 5000 individuals or devices. 
+
+  c. If we generate anonymized datasets under this exception we will publicly
+     document our anonymization methods in sufficient detail to allow outside
+     experts to evaluate the effectiveness of those methods.
+
+5. ERRORS: 
+
+From time to time, there may be errors by which user data is temporarily
+logged or retained in violation of this policy.  If such errors are
+inadvertent, rare, and made in good faith, they do not constitute a breach
+of this policy.  We will delete such data as soon as practicable after we
+become aware of any error and take steps to ensure that it is deleted by any
+third-party who may have had access to the data.
+
+ADDITIONAL DEFINITIONS
+
+"Fully Qualified Domain Name" means a domain name that addresses a computer
+connected to the Internet.  For instance, example1.com; www.example1.com;
+ads.example1.com; and widgets.example2.com are all distinct FQDNs.
+
+"Supercookie" means any technology other than an HTTP Cookie which can be used
+by a server to associate identifiers with the clients that visit it.  Examples
+of supercookies include Flash LSO cookies, DOM storage, HTML5 storage, or
+tricks to store information in caches or etags.
+
+"Risk mitigation" means an engineering process that evaluates the possibility
+and likelihood of various adverse outcomes, considers the available methods of
+making those adverse outcomes less likely, and deploys sufficient mitigations
+to bring the probability and harm from adverse outcomes below an acceptable
+threshold.
+
+"Reading habits" includes amongst other things lists of visited DNS names, if
+those domains pertain to specific topics or activities, but records of visited
+DNS names are not reading habits if those domain names serve content of a very
+diverse and general nature, thereby revealing minimal information about the
+opinions, interests or activities of the user.
\ No newline at end of file

uris/matrix/client

+{
+  "m.homeserver": {
+    "base_url": "https://matrix.iiens.net"
+  }
+}

uris/matrix/server

+{
+  "m.server": "matrix.iiens.net:443"
+}

uris/security.txt

+Contact: mailto:arise@iiens.net
+Expires: Sat, 31 Dec 2050 23:59:59
+Preferred-Languages: fr, en