harukin/core
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doco updates

Browse Source
This commit is contained in:
redmatrix 2016-08-22 16:46:44 -07:00
parent d177cf94da
commit d6d21cb5f6
4 changed files with 155 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

106
doc/contributor/covenant.html Normal file
View File

@ -0,0 +1,106 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title>Contributor Covenant 1.4.0</title>
<style>
body {
font-family: monospace;
padding: 4em;
}
a {
color: #990000;
}
</style>
<link rel="alternate" hreflang="de" href="version/1/3/0/de/" />
<link rel="alternate" hreflang="es" href="version/1/4/es/" />
<link rel="alternate" hreflang="fr" href="version/1/3/0/fr/" />
<link rel="alternate" hreflang="hu" href="version/1/3/0/hu/" />
<link rel="alternate" hreflang="it" href="version/1/3/0/it/" />
<link rel="alternate" hreflang="ja" href="version/1/3/0/ja/" />
<link rel="alternate" hreflang="pl" href="version/1/4/pl/" />
<link rel="alternate" hreflang="pt" href="version/1/3/0/pt/" />
<link rel="alternate" hreflang="pt" href="version/1/3/0/pt_br/" />
<link rel="alternate" hreflang="ru" href="version/1/3/0/ru/" />
<link rel="alternate" hreflang="sl" href="version/1/4/sl/" />
<link rel="alternate" hreflang="uk" href="version/1/4/uk/" />
</head>
<body>
<h1>Contributor Covenant Code of Conduct</h1>
<h2>Our Pledge</h2>
<p>In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.</p>
<h2>Our Standards</h2>
<p>Examples of behavior that contributes to creating a positive environment
include:</p>
<ul>
<li>Using welcoming and inclusive language</li>
<li>Being respectful of differing viewpoints and experiences</li>
<li>Gracefully accepting constructive criticism</li>
<li>Focusing on what is best for the community</li>
<li>Showing empathy towards other community members</li>
</ul>
<p>Examples of unacceptable behavior by participants include:</p>
<ul>
<li>The use of sexualized language or imagery and unwelcome sexual attention or advances</li>
<li>Trolling, insulting/derogatory comments, and personal or political attacks</li>
<li>Public or private harassment</li>
<li>Publishing others' private information, such as a physical or electronic address, without explicit permission</li>
<li>Other conduct which could reasonably be considered inappropriate in a professional setting</li>
</ul>
<h2>Our Responsibilities</h2>
<p>Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.</p>
<p>Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.</p>
<h2>Scope</h2>
<p>This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.</p>
<h2>Enforcement</h2>
<p>Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at project&#x40;hubzilla.org. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.</p>
<p>Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.</p>
<h2>Attribution</h2>
<p>This Code of Conduct is adapted from the <a href="http://contributor-covenant.org">Contributor Covenant</a>, version 1.4,
available at <a href="http://contributor-covenant.org/version/1/4/">http://contributor-covenant.org/version/1/4</a>.</p>
</body>
</html>

2
doc/develop.bb
View File

@ -27,5 +27,5 @@
[zrl=[baseurl]/help/dev_beginner]Step-for-step manual for beginning developers[/zrl] [zrl=[baseurl]/help/dev_beginner]Step-for-step manual for beginning developers[/zrl]
[h3]External Resources[/h3] [h3]External Resources[/h3]
[url=https://zothub.com/channel/one]Development Channel[/url] [url=https://grid.reticu.li/channel/hubzilla]Development Channel[/url]
[url=https://federated.social/channel/postgres]Postgres-specific $Projectname Admin Support Channel[/url] [url=https://federated.social/channel/postgres]Postgres-specific $Projectname Admin Support Channel[/url]

2
doc/developers.bb
View File

@ -1,6 +1,6 @@
[b]$Projectname Developer Guide[/b] [b]$Projectname Developer Guide[/b]
We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine. We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. All developers are expected to abide by our [zrl=[baseurl]/help/contributor/covenant]code of conduct[/zrl]. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine.
[b]Here is how you can join us.[/b] [b]Here is how you can join us.[/b]

47
doc/feature/access_tokens.bb Normal file
View File

@ -0,0 +1,47 @@
Feature: Zot Access Tokens
Status: Draft
Date: 15 July 2016
Purpose:
In order to facilitate sharing of private resources with non-members or members of federation nodes with limited identification discovery, Hubzilla should provide members with a mechanism to create and manage temporary ("throwaway") logins, aka "Zot Access Tokens". These tokens/credentials may be used to authenticate to a hubzilla site for the sole purpose of accessing privileged or access controlled resources (files, photos, posts, webpages, chatrooms, etc.).
Scope:
Zot Access Tokens do not convey membership in the site or network. In particular, they do not provide an account or channel; which may be necessary to interact with the hub owner or with others in the network or federation of networks. In most cases they can only be used to consume restricted resources and do not have an ability to create those resources, however this ability may be provided by custom configurations or in future releases or addons.
For instance the ability for a temporary login to access a chatroom may provide suitable permission to create chat messages inside that chatroom.
Implementation:
Zot Access Tokens are managed through a "tab" of the settings page. Access to this tab may be controlled by site configuration. On this page, channels may create, edit, list, and remove any access tokens under their control.
The form to create/edit accepts three parameters, a human readable name, a password or access token, and an optional expiration. Once expired, the access token is no longer valid, may no longer be used, and will be automatically purged from the list of temporary accounts. The password field in the create/edit forms displays the text of the access token and not an obscured password. By default we will create a token using the autoname() function, which generally produces a random character sequence which is "pronounceable", hence easy to convey or remember. This can be changed to any other character sequence which is acceptable to the site password complexity policy. (In most Hubzilla installations this imposes a minimum of three characters, but may be extended by plugin or site policy).
Usage:
We do not specify mechanisms for sharing these tokens with others. Any communication method may be used. Any tokens you have created are added to the Access Control List selector and may be used anywhere that Access Control Lists are provided.
Example: A visitor arrives at your site. She has an access token you have provided, and attempts to visit one of your photo albums (which is restricted to be viewed only by yourself and one temporary identity). Permission is denied.
The visitor now selects "Login" from the menu navigation bar. This presents a login page. She enters the name and password you have provided her, and she can now view the restricted photo album.
Alternatively, you may share a link to a protected file by adding a parameter "&zat=abc123" to the URL, where the string "abc123" is the access token or password for the temporary login. No further negotiation is required, and the file is presented.
Zot Acess Tokens are represented internally as an authenticated "observer". Querying the observer in code should return a pseudo or system generated xchan with an unknown protocol and a default profile photo. It will match (successfully) any access control rule which allows authenticated observers.
Security Considerations:
The URL form of authentication is inherently less secure than using a login, but may be preferable for some uses of this feature. It probably should not be transmitted over non-SSL links.
Future development:
It might be desirable for future implementations to provide an options for single-use, where the access token is removed promptly following first use.