diff --git a/.gitignore b/.gitignore index 836a4b1..1e36ebf 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,115 @@ cache public -content *.pyc pelican.pid srv.pid +themes/i18n/translations/*/LC_MESSAGES/*.mo +env + +# This is a generic Python gitignore +# https://github.com/github/gitignore/blob/2eba0d635f6f5f1b22a4ad99dcc9da0c11da2208/Python.gitignore + +# Byte-compiled / optimized / DLL files +__pycache__/ +*.py[cod] +*$py.class + +# C extensions +*.so + +# Distribution / packaging +.Python +build/ +develop-eggs/ +dist/ +downloads/ +eggs/ +.eggs/ +lib/ +lib64/ +parts/ +sdist/ +var/ +wheels/ +*.egg-info/ +.installed.cfg +*.egg +MANIFEST + +# PyInstaller +# Usually these files are written by a python script from a template +# before PyInstaller builds the exe, so as to inject date/other infos into it. +*.manifest +*.spec + +# Installer logs +pip-log.txt +pip-delete-this-directory.txt + +# Unit test / coverage reports +htmlcov/ +.tox/ +.coverage +.coverage.* +.cache +nosetests.xml +coverage.xml +*.cover +.hypothesis/ +.pytest_cache/ + +# Translations +*.mo +*.pot + +# Django stuff: +*.log +local_settings.py +db.sqlite3 + +# Flask stuff: +instance/ +.webassets-cache + +# Scrapy stuff: +.scrapy + +# Sphinx documentation +docs/_build/ + +# PyBuilder +target/ + +# Jupyter Notebook +.ipynb_checkpoints + +# pyenv +.python-version + +# celery beat schedule file +celerybeat-schedule + +# SageMath parsed files +*.sage.py + +# Environments +.env +.venv +env/ +venv/ +ENV/ +env.bak/ +venv.bak/ + +# Spyder project settings +.spyderproject +.spyproject + +# Rope project settings +.ropeproject + +# mkdocs documentation +/site + +# mypy +.mypy_cache/ diff --git a/.gitmodules b/.gitmodules deleted file mode 100644 index a6f1315..0000000 --- a/.gitmodules +++ /dev/null @@ -1,3 +0,0 @@ -[submodule "Font-Awesome"] - path = themes/website/static/Font-Awesome - url = https://github.com/FortAwesome/Font-Awesome diff --git a/content/blog/2015-07-11_current-situation-3.de.md b/content/blog/2015-07-11_current-situation-3.de.md new file mode 100644 index 0000000..a45af1f --- /dev/null +++ b/content/blog/2015-07-11_current-situation-3.de.md @@ -0,0 +1,74 @@ +Title: Current Situation +Date: 2015-07-11 00:55 +Author: Project Tox +Category: Uncategorized +Status: published + +As many of you in the Tox community have likely already heard, a serious +situation was brought to our attention which has forced the +Tox development team to disassociate itself from the Tox Foundation, +along with its sole board member, Sean Qureshi (aka Stqism, aka +AlexStraunoff, aka NikolaiToryzin). We learned by Sean’s own +admission that he "took a loan against the Tox Foundation", and used the +entirety of the foundation’s funds on personal expenses completely +unrelated to the project. He did not inform anyone about his actions +prior to taking them, then proceeded to disappear for weeks once we +found out, ignoring our attempts to contact him and get an explanation. + +The exact amount that he took is unknown due to his having complete +control over our finances, but it is in the low-thousands. This fund +regrettably included a small amount of donation money, but was primarily +made up of money that we received by participating in Google Summer of +Code last summer. + +First, we want to sincerely apologize to the community and take +responsibility. We could not have predicted that something like this +would happen, but we certainly could have handled our finances in a more +responsible and transparent manner. While our development team consists +of many skilled programmers and designers, none of us are experienced in +business or financial matters. This led us to put too much trust and +power into the hands of a single person, who turned out to be just the +sort of person who would take advantage of such a situation. We can +blame no one but ourselves for this. + +Unfortunately, Sean refuses to take responsibility for what he has done, +and seems to carry the attitude that what he did was perfectly +acceptable. Despite our having spent a great deal of time and effort +trying to engage with him, giving him opportunities to pay us back and +redeem himself (which is part of the reason why we have waited this long +to make an official post about it), he has shown no remorse for his +actions, and continues to hold some of our infrastructure "hostage". +This includes the tox.im, toxme.se, and libtoxcore.so domains. For this +reason, we have have also been forced to disassociate ourselves with the +aforementioned domains and begin again from scratch with a new domain, +tox.chat. + +In spite of the damage that has been done—which we do not wish to +understate—we'd like to look on the bright side of things and consider +this a very expensive lesson learned in project management, and life in +general. We've lost some money, but we've gained a ton of insight. We +have also been lucky enough to have a few long-standing members of the +community step up and help us out with things like server management, +and we should have everything back to normal in a short while, with a +stronger and better equipped team than before. + +As far as finances go, we are not going to repeat the same mistakes +twice. We will not be taking any official donations\* until we have set +up a proper organization with an emphasis on transparency and protection +of assets (more details on this at a future date). + +In the mean time, we hope that you will continue to support us, if not +financially, then in spirit. Despite all of this drama, we have not lost +sight of our vision to provide secure, private communications for +everyone. Tox development hasn't had so much as a hiccup in the midst of +all this; our second run at Google Summer of Code is going better than +our first, and the number of enthusiastic developers who share our +vision continues to grow. + +Thank you for your understanding and continued support. + +\* If you still want to give personal donations to individual +developers, most of us have bitcoin wallets or paypal accounts and can +be reached in IRC ([\#tox](https://webchat.freenode.net/?channels=#tox) +and [\#tox-dev](https://webchat.freenode.net/?channels=#tox-dev) @ +freenode) diff --git a/content/blog/2015-07-11_current-situation-3.en.md b/content/blog/2015-07-11_current-situation-3.en.md new file mode 100644 index 0000000..a45af1f --- /dev/null +++ b/content/blog/2015-07-11_current-situation-3.en.md @@ -0,0 +1,74 @@ +Title: Current Situation +Date: 2015-07-11 00:55 +Author: Project Tox +Category: Uncategorized +Status: published + +As many of you in the Tox community have likely already heard, a serious +situation was brought to our attention which has forced the +Tox development team to disassociate itself from the Tox Foundation, +along with its sole board member, Sean Qureshi (aka Stqism, aka +AlexStraunoff, aka NikolaiToryzin). We learned by Sean’s own +admission that he "took a loan against the Tox Foundation", and used the +entirety of the foundation’s funds on personal expenses completely +unrelated to the project. He did not inform anyone about his actions +prior to taking them, then proceeded to disappear for weeks once we +found out, ignoring our attempts to contact him and get an explanation. + +The exact amount that he took is unknown due to his having complete +control over our finances, but it is in the low-thousands. This fund +regrettably included a small amount of donation money, but was primarily +made up of money that we received by participating in Google Summer of +Code last summer. + +First, we want to sincerely apologize to the community and take +responsibility. We could not have predicted that something like this +would happen, but we certainly could have handled our finances in a more +responsible and transparent manner. While our development team consists +of many skilled programmers and designers, none of us are experienced in +business or financial matters. This led us to put too much trust and +power into the hands of a single person, who turned out to be just the +sort of person who would take advantage of such a situation. We can +blame no one but ourselves for this. + +Unfortunately, Sean refuses to take responsibility for what he has done, +and seems to carry the attitude that what he did was perfectly +acceptable. Despite our having spent a great deal of time and effort +trying to engage with him, giving him opportunities to pay us back and +redeem himself (which is part of the reason why we have waited this long +to make an official post about it), he has shown no remorse for his +actions, and continues to hold some of our infrastructure "hostage". +This includes the tox.im, toxme.se, and libtoxcore.so domains. For this +reason, we have have also been forced to disassociate ourselves with the +aforementioned domains and begin again from scratch with a new domain, +tox.chat. + +In spite of the damage that has been done—which we do not wish to +understate—we'd like to look on the bright side of things and consider +this a very expensive lesson learned in project management, and life in +general. We've lost some money, but we've gained a ton of insight. We +have also been lucky enough to have a few long-standing members of the +community step up and help us out with things like server management, +and we should have everything back to normal in a short while, with a +stronger and better equipped team than before. + +As far as finances go, we are not going to repeat the same mistakes +twice. We will not be taking any official donations\* until we have set +up a proper organization with an emphasis on transparency and protection +of assets (more details on this at a future date). + +In the mean time, we hope that you will continue to support us, if not +financially, then in spirit. Despite all of this drama, we have not lost +sight of our vision to provide secure, private communications for +everyone. Tox development hasn't had so much as a hiccup in the midst of +all this; our second run at Google Summer of Code is going better than +our first, and the number of enthusiastic developers who share our +vision continues to grow. + +Thank you for your understanding and continued support. + +\* If you still want to give personal donations to individual +developers, most of us have bitcoin wallets or paypal accounts and can +be reached in IRC ([\#tox](https://webchat.freenode.net/?channels=#tox) +and [\#tox-dev](https://webchat.freenode.net/?channels=#tox-dev) @ +freenode) diff --git a/content/blog/2015-08-08_tox-dev-talks-1.de.md b/content/blog/2015-08-08_tox-dev-talks-1.de.md new file mode 100644 index 0000000..0dbdc62 --- /dev/null +++ b/content/blog/2015-08-08_tox-dev-talks-1.de.md @@ -0,0 +1,52 @@ +Title: Tox Dev Talks - #1 +Date: 2015-08-08 23:29 +Author: areashr +Category: Tox Dev Talks +Status: published + +*(If you don't already know, Tox Dev Talks is a series of weekly +meetings that bring the Tox developer community together to share ideas, +progress, and miscellaneous chatter. They take place every Saturday at +03:00 UTC.)* + +This week's Tox Dev Talk turned out exceptionally well, especially as it +was the first one. The primary focus was on mobile issues; here is a +summary of what was discussed. + +- How do we deal with doze mode in Android M? + - Do we use GCM? +- Is a "passive mode" for toxcore so we can reduce battery and data + usage possible? +- How do we deal with backgrounding restrictions on iOS? + - Possible solution: use VoIP sockets. +- No concrete decisions as of now. + + + +- qTox: as tux3 has been absent for a while, the main repo might be + moved to DaSpirit's fork. + +**Progress updates and to-do:** + +- **installgen2 (Web)** + - ToxKek - Fix connection and crash bugs, add mobile frontend + design, add avatars, add file transfers, add ToxDNS support, add + groupchat support, add memes, and add remote server support. + *(ToxKek is an early-stage HTML/JS Tox client.)* + - Tox.Party - Add Tox3 support and get https certificate. + - Tox Wiki - Add missing pages and clean up mess +- **chuongv (iOS)** + - Antidote: Implement video calls for this week. +- **subliun (Android)** + - Antox: working on encrypted profile support, fixing some bugs, + and getting ready for av support. + - New ToxDNS host is toxme.io +- **Impyy (C\#/Windows)** + - SharpTox - finish new groupchat bindings, write documentation + for both new av api and new groupchat api. +- **oranges (Build infrastructure)** + - Jenkins is up and building libraries, some clients are building. + - Waiting on client devs for some of the other clients. + +We hope to see more of the same kind of constructive discussion, and +more developers in attendance next week! diff --git a/content/blog/2015-08-08_tox-dev-talks-1.en.md b/content/blog/2015-08-08_tox-dev-talks-1.en.md new file mode 100644 index 0000000..0dbdc62 --- /dev/null +++ b/content/blog/2015-08-08_tox-dev-talks-1.en.md @@ -0,0 +1,52 @@ +Title: Tox Dev Talks - #1 +Date: 2015-08-08 23:29 +Author: areashr +Category: Tox Dev Talks +Status: published + +*(If you don't already know, Tox Dev Talks is a series of weekly +meetings that bring the Tox developer community together to share ideas, +progress, and miscellaneous chatter. They take place every Saturday at +03:00 UTC.)* + +This week's Tox Dev Talk turned out exceptionally well, especially as it +was the first one. The primary focus was on mobile issues; here is a +summary of what was discussed. + +- How do we deal with doze mode in Android M? + - Do we use GCM? +- Is a "passive mode" for toxcore so we can reduce battery and data + usage possible? +- How do we deal with backgrounding restrictions on iOS? + - Possible solution: use VoIP sockets. +- No concrete decisions as of now. + + + +- qTox: as tux3 has been absent for a while, the main repo might be + moved to DaSpirit's fork. + +**Progress updates and to-do:** + +- **installgen2 (Web)** + - ToxKek - Fix connection and crash bugs, add mobile frontend + design, add avatars, add file transfers, add ToxDNS support, add + groupchat support, add memes, and add remote server support. + *(ToxKek is an early-stage HTML/JS Tox client.)* + - Tox.Party - Add Tox3 support and get https certificate. + - Tox Wiki - Add missing pages and clean up mess +- **chuongv (iOS)** + - Antidote: Implement video calls for this week. +- **subliun (Android)** + - Antox: working on encrypted profile support, fixing some bugs, + and getting ready for av support. + - New ToxDNS host is toxme.io +- **Impyy (C\#/Windows)** + - SharpTox - finish new groupchat bindings, write documentation + for both new av api and new groupchat api. +- **oranges (Build infrastructure)** + - Jenkins is up and building libraries, some clients are building. + - Waiting on client devs for some of the other clients. + +We hope to see more of the same kind of constructive discussion, and +more developers in attendance next week! diff --git a/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.de.md b/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.de.md new file mode 100644 index 0000000..3f8d37c --- /dev/null +++ b/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.de.md @@ -0,0 +1,32 @@ +Title: Regarding irungentoo's Indiegogo Campaign +Date: 2015-08-09 22:00 +Author: nurupo +Category: Uncategorized +Status: published + +[irungentoo](https://github.com/irungentoo) (our main toxcore developer) +has started [a personal fundraising +campaign](https://www.indiegogo.com/projects/toxcore-development) that +would allow him to dedicate a month of full time work to Tox +development. Although this has already been posted +on [Twitter](https://twitter.com/projecttox), +[reddit](https://reddit.com/r/projecttox) and +[IRC](https://wiki.tox.chat/users/community#irc), we have decided to +give it a mention here as well, both in order to support our fellow +developer, and to clear up some misunderstandings. + +Quite a few people have asked if this is an official Tox fundraising +campaign. It is not. This is something that irungentoo is doing on his +own, separate from the project; all raised funds will go directly to him +to be used however he sees best fit. We mentioned in our [previous blog +post]({filename}2015-07-11_current-situation-3.en.md) that we +wouldn't be taking any donations as a project until we have set up a +proper organization with an emphasis on transparency and protection of +assets. This is still the case, however we also mentioned that +individual developers are free to take personal donations, which is what +this is. + +We apologize if this has caused any confusion, and hope that this has +sufficiently cleared up any misunderstandings. + + diff --git a/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.en.md b/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.en.md new file mode 100644 index 0000000..3f8d37c --- /dev/null +++ b/content/blog/2015-08-09_regarding-irungentoos-indiegogo-campaign.en.md @@ -0,0 +1,32 @@ +Title: Regarding irungentoo's Indiegogo Campaign +Date: 2015-08-09 22:00 +Author: nurupo +Category: Uncategorized +Status: published + +[irungentoo](https://github.com/irungentoo) (our main toxcore developer) +has started [a personal fundraising +campaign](https://www.indiegogo.com/projects/toxcore-development) that +would allow him to dedicate a month of full time work to Tox +development. Although this has already been posted +on [Twitter](https://twitter.com/projecttox), +[reddit](https://reddit.com/r/projecttox) and +[IRC](https://wiki.tox.chat/users/community#irc), we have decided to +give it a mention here as well, both in order to support our fellow +developer, and to clear up some misunderstandings. + +Quite a few people have asked if this is an official Tox fundraising +campaign. It is not. This is something that irungentoo is doing on his +own, separate from the project; all raised funds will go directly to him +to be used however he sees best fit. We mentioned in our [previous blog +post]({filename}2015-07-11_current-situation-3.en.md) that we +wouldn't be taking any donations as a project until we have set up a +proper organization with an emphasis on transparency and protection of +assets. This is still the case, however we also mentioned that +individual developers are free to take personal donations, which is what +this is. + +We apologize if this has caused any confusion, and hope that this has +sufficiently cleared up any misunderstandings. + + diff --git a/content/blog/2015-08-22_tox-dev-talks-2.de.md b/content/blog/2015-08-22_tox-dev-talks-2.de.md new file mode 100644 index 0000000..4d47ffb --- /dev/null +++ b/content/blog/2015-08-22_tox-dev-talks-2.de.md @@ -0,0 +1,70 @@ +Title: Tox Dev Talks – #2 +Date: 2015-08-22 12:32 +Author: areashr +Category: Tox Dev Talks +Status: published + +*(Tox Dev Talks is a series of weekly meetings that bring the Tox +developer community together to share ideas, progress, +and miscellaneous chatter. They take place Saturdays at 16:00 UTC.)* + +Tox Dev Talks are back after a week-long hiatus due to scheduling +difficulties. As we had irungentoo on hand, we spent a lot of time on +core issues. Here's a bit of what was discussed. + +- **Tox core** + - **Offline messaging** + - The student who was implementing it disappeared. irungentoo + will be taking over if he has time. + - **Friendly names / DNS replacement?** + - No real solution was brought up that would be better than + what we have now. That said, DNS will remain optional for + clients and not a Tox core feature. + - **irungentoo's to-do list** + - Improve file transfers. + - Write proper documentation for the code. + - In general, fix bugs and/or finish some features that aren’t + done. + - **New groupchats** + - Currently stalled due to requiring some significant core + changes. + - **A/V revamp** + - Currently waiting on client support and some important bug + fixes. + + + +- **Packaging** + - qTox binaries are finally available again (Windows and Linux + static) + - An APT repository will be coming soon. + + + +- **Client news** + - µTox + - New A/V is complete and waiting on aforementioned bug fixes. + - grayhatter is currently working to improve the UI. + - qTox + - New A/V is almost done, audio works, webcam works, streaming + desktop doesn’t work and the button functionality still + needs to be implemented. + - tux3 is no longer dead, and has given access to the main + repository to DaSpirit and others while he catches up on + things. + - Antox + - There is currently a naming dispute with the original + author. + - The current developer, subliun, will continue using the + Antox name. + + + +- **Other things worth mentioning** + - As some people aren't happy with the design of tox.chat, + installgen2 is going to redesign the site. He will show what he + came up with at the next meeting. + +If you want to participate in the next Tox Dev Talk, feel free to drop +in next week. We hope to keep a stable schedule, but if that doesn't +happen, we will let you know on [the calendar](/events). diff --git a/content/blog/2015-08-22_tox-dev-talks-2.en.md b/content/blog/2015-08-22_tox-dev-talks-2.en.md new file mode 100644 index 0000000..4d47ffb --- /dev/null +++ b/content/blog/2015-08-22_tox-dev-talks-2.en.md @@ -0,0 +1,70 @@ +Title: Tox Dev Talks – #2 +Date: 2015-08-22 12:32 +Author: areashr +Category: Tox Dev Talks +Status: published + +*(Tox Dev Talks is a series of weekly meetings that bring the Tox +developer community together to share ideas, progress, +and miscellaneous chatter. They take place Saturdays at 16:00 UTC.)* + +Tox Dev Talks are back after a week-long hiatus due to scheduling +difficulties. As we had irungentoo on hand, we spent a lot of time on +core issues. Here's a bit of what was discussed. + +- **Tox core** + - **Offline messaging** + - The student who was implementing it disappeared. irungentoo + will be taking over if he has time. + - **Friendly names / DNS replacement?** + - No real solution was brought up that would be better than + what we have now. That said, DNS will remain optional for + clients and not a Tox core feature. + - **irungentoo's to-do list** + - Improve file transfers. + - Write proper documentation for the code. + - In general, fix bugs and/or finish some features that aren’t + done. + - **New groupchats** + - Currently stalled due to requiring some significant core + changes. + - **A/V revamp** + - Currently waiting on client support and some important bug + fixes. + + + +- **Packaging** + - qTox binaries are finally available again (Windows and Linux + static) + - An APT repository will be coming soon. + + + +- **Client news** + - µTox + - New A/V is complete and waiting on aforementioned bug fixes. + - grayhatter is currently working to improve the UI. + - qTox + - New A/V is almost done, audio works, webcam works, streaming + desktop doesn’t work and the button functionality still + needs to be implemented. + - tux3 is no longer dead, and has given access to the main + repository to DaSpirit and others while he catches up on + things. + - Antox + - There is currently a naming dispute with the original + author. + - The current developer, subliun, will continue using the + Antox name. + + + +- **Other things worth mentioning** + - As some people aren't happy with the design of tox.chat, + installgen2 is going to redesign the site. He will show what he + came up with at the next meeting. + +If you want to participate in the next Tox Dev Talk, feel free to drop +in next week. We hope to keep a stable schedule, but if that doesn't +happen, we will let you know on [the calendar](/events). diff --git a/content/blog/2015-08-29_tox-dev-talks-3.de.md b/content/blog/2015-08-29_tox-dev-talks-3.de.md new file mode 100644 index 0000000..3ca090f --- /dev/null +++ b/content/blog/2015-08-29_tox-dev-talks-3.de.md @@ -0,0 +1,54 @@ +Title: Tox Dev Talks – #3 +Date: 2015-08-29 13:47 +Author: installgen2 +Category: Tox Dev Talks +Status: published + +*(Tox Dev Talks is a series of weekly meetings that bring the Tox +developer community together to share ideas, progress, +and miscellaneous chatter. They take place Saturdays at 16:00 UTC.)* + +In this week's meeting, as usual, we discussed a variety of topics, +which have been summarized below. + +*(Edited 2015/08/30: a few factual corrections were made. Apologies for +letting them slip past editing -ak)* + +- **Binaries** + - **Package signing** + - Jenkins will handle it + - Possibility of making Jenkins push notify on changes +- **Policy** + - **\#tox-dev** + - We discussed how much off-topic discussion and other noise + we are willing to allow on \#tox-dev + - Possibly enabling colors for improved build info + - nurupo expressed concern of color misuse + - **Social media** + - We reminded the managers of each Tox-related account of + their responsibilities + - **Blog** + - Social media will now link to EVERY blog post + - GSoC mentors should come up with a GSoC blog post +- **Our website** + - installgen2 is working on redesigning tox.chat from scratch, + this will take 3-7 days to complete +- **ToxAV** + - Mannol has said there will be more commits this (2015-08-29) + weekend +- **New groupchats** + - JFreegman is still waiting on irungentoo to implement the + difficult codebase changes +- **Core and client updates** + - **qTox** + - Zetok will be tagging qTox issues + - **uTox** + - in-progress UI redesign + - New groupchats once ToxAV gets merged, and the refactor in + that branch gets merged +- **Other developments** + - nurupo is working on fixing bugs and refactoring code in code + base of GSoC project he mentored + - codedust is developing – a + web based tox client + diff --git a/content/blog/2015-08-29_tox-dev-talks-3.en.md b/content/blog/2015-08-29_tox-dev-talks-3.en.md new file mode 100644 index 0000000..3ca090f --- /dev/null +++ b/content/blog/2015-08-29_tox-dev-talks-3.en.md @@ -0,0 +1,54 @@ +Title: Tox Dev Talks – #3 +Date: 2015-08-29 13:47 +Author: installgen2 +Category: Tox Dev Talks +Status: published + +*(Tox Dev Talks is a series of weekly meetings that bring the Tox +developer community together to share ideas, progress, +and miscellaneous chatter. They take place Saturdays at 16:00 UTC.)* + +In this week's meeting, as usual, we discussed a variety of topics, +which have been summarized below. + +*(Edited 2015/08/30: a few factual corrections were made. Apologies for +letting them slip past editing -ak)* + +- **Binaries** + - **Package signing** + - Jenkins will handle it + - Possibility of making Jenkins push notify on changes +- **Policy** + - **\#tox-dev** + - We discussed how much off-topic discussion and other noise + we are willing to allow on \#tox-dev + - Possibly enabling colors for improved build info + - nurupo expressed concern of color misuse + - **Social media** + - We reminded the managers of each Tox-related account of + their responsibilities + - **Blog** + - Social media will now link to EVERY blog post + - GSoC mentors should come up with a GSoC blog post +- **Our website** + - installgen2 is working on redesigning tox.chat from scratch, + this will take 3-7 days to complete +- **ToxAV** + - Mannol has said there will be more commits this (2015-08-29) + weekend +- **New groupchats** + - JFreegman is still waiting on irungentoo to implement the + difficult codebase changes +- **Core and client updates** + - **qTox** + - Zetok will be tagging qTox issues + - **uTox** + - in-progress UI redesign + - New groupchats once ToxAV gets merged, and the refactor in + that branch gets merged +- **Other developments** + - nurupo is working on fixing bugs and refactoring code in code + base of GSoC project he mentored + - codedust is developing – a + web based tox client + diff --git a/content/blog/2015-09-01_sound-design.de.md b/content/blog/2015-09-01_sound-design.de.md new file mode 100644 index 0000000..a32c119 --- /dev/null +++ b/content/blog/2015-09-01_sound-design.de.md @@ -0,0 +1,16 @@ +Title: Sound design! +Date: 2015-09-01 15:48 +Author: installgen2 +Category: Uncategorized +Status: published + +As I'm sure you are all aware, Tox has grown tremendously in terms of UI +and usability, yet client sounds are still somewhat lacking. + +We are looking for people to help out with creating sounds for clients +(ringtones, notification sounds, etc). No programming knowledge is +required. Just join us in \#tox-dev on Freenode (here is +[webchat](https://webchat.freenode.net/?channels=#tox-dev) for those of +you without an IRC client). + +Thanks! diff --git a/content/blog/2015-09-01_sound-design.en.md b/content/blog/2015-09-01_sound-design.en.md new file mode 100644 index 0000000..a32c119 --- /dev/null +++ b/content/blog/2015-09-01_sound-design.en.md @@ -0,0 +1,16 @@ +Title: Sound design! +Date: 2015-09-01 15:48 +Author: installgen2 +Category: Uncategorized +Status: published + +As I'm sure you are all aware, Tox has grown tremendously in terms of UI +and usability, yet client sounds are still somewhat lacking. + +We are looking for people to help out with creating sounds for clients +(ringtones, notification sounds, etc). No programming knowledge is +required. Just join us in \#tox-dev on Freenode (here is +[webchat](https://webchat.freenode.net/?channels=#tox-dev) for those of +you without an IRC client). + +Thanks! diff --git a/content/blog/2015-09-05_successful-indiegogo.de.md b/content/blog/2015-09-05_successful-indiegogo.de.md new file mode 100644 index 0000000..ef7f602 --- /dev/null +++ b/content/blog/2015-09-05_successful-indiegogo.de.md @@ -0,0 +1,49 @@ +Title: Successful Indiegogo Campaign! +Date: 2015-09-05 21:31 +Author: Project Tox +Category: Uncategorized +Status: published + +We are happy to announce that irungentoo's personal Indiegogo campaign +has been successfully funded! + +![Sketch of irungentoo receiving Indiegogo campaign money]({filename}static/images/irungentoo-indiegogo.png) + +As you may already know, irungentoo has been running a [personal +fundraiser]({filename}2015-08-09_regarding-irungentoos-indiegogo-campaign.en.md), +to allow himself to dedicate a month of full time work to Tox +development. This fundraiser reached +its \$5,000 USD goal with 6 hours left on the clock. At the time of +writing, a total of **\$5,785** has been +raised by **217** funders. + +The Tox Project would like to give a big "Thank You!" to all that +donated, as well as to all of Tox's supporters for making this happen, +and helping to raise even more money than irungentoo's original goal. + +irungentoo would like to say to everyone: + +> Thank you, everyone, for making this fundraiser a success. If you +> bought a perk please send me the related stuff, it will be put into +> the repository when I collect most of them. If you donated bitcoin in +> an amount equal or greater to the value of one of the perks and want +> to receive that perk, just email me at **irungentoo@gmail.com** with +> proof (e.g. a message signed with your bitcoin address key). +> +> Unless something happens (computer stops working, etc.), I will be +> starting my full time work on toxcore on September 8. I will start by +> writing toxcore documentation, which will take a long time but is +> important and might invite more people to contribute to toxcore and +> make sure that Tox does not die if I get hit by a bus. Thank you for +> making sure that Tox will become even stronger. +> +> Sincerely, +> irungentoo + +We'll be sitting down with irungentoo very soon to develop a roadmap for +the toxcore library. Once it has been developed, we'll publish it, and +you'll be able to track development progress as it happens. + +Thanks again, + +The Tox Project diff --git a/content/blog/2015-09-05_successful-indiegogo.en.md b/content/blog/2015-09-05_successful-indiegogo.en.md new file mode 100644 index 0000000..ef7f602 --- /dev/null +++ b/content/blog/2015-09-05_successful-indiegogo.en.md @@ -0,0 +1,49 @@ +Title: Successful Indiegogo Campaign! +Date: 2015-09-05 21:31 +Author: Project Tox +Category: Uncategorized +Status: published + +We are happy to announce that irungentoo's personal Indiegogo campaign +has been successfully funded! + +![Sketch of irungentoo receiving Indiegogo campaign money]({filename}static/images/irungentoo-indiegogo.png) + +As you may already know, irungentoo has been running a [personal +fundraiser]({filename}2015-08-09_regarding-irungentoos-indiegogo-campaign.en.md), +to allow himself to dedicate a month of full time work to Tox +development. This fundraiser reached +its \$5,000 USD goal with 6 hours left on the clock. At the time of +writing, a total of **\$5,785** has been +raised by **217** funders. + +The Tox Project would like to give a big "Thank You!" to all that +donated, as well as to all of Tox's supporters for making this happen, +and helping to raise even more money than irungentoo's original goal. + +irungentoo would like to say to everyone: + +> Thank you, everyone, for making this fundraiser a success. If you +> bought a perk please send me the related stuff, it will be put into +> the repository when I collect most of them. If you donated bitcoin in +> an amount equal or greater to the value of one of the perks and want +> to receive that perk, just email me at **irungentoo@gmail.com** with +> proof (e.g. a message signed with your bitcoin address key). +> +> Unless something happens (computer stops working, etc.), I will be +> starting my full time work on toxcore on September 8. I will start by +> writing toxcore documentation, which will take a long time but is +> important and might invite more people to contribute to toxcore and +> make sure that Tox does not die if I get hit by a bus. Thank you for +> making sure that Tox will become even stronger. +> +> Sincerely, +> irungentoo + +We'll be sitting down with irungentoo very soon to develop a roadmap for +the toxcore library. Once it has been developed, we'll publish it, and +you'll be able to track development progress as it happens. + +Thanks again, + +The Tox Project diff --git a/content/blog/2015-09-12_fuzzing-the-new-groupchats.de.md b/content/blog/2015-09-12_fuzzing-the-new-groupchats.de.md new file mode 100644 index 0000000..a3a5c63 --- /dev/null +++ b/content/blog/2015-09-12_fuzzing-the-new-groupchats.de.md @@ -0,0 +1,159 @@ +Title: Fuzzing The New Groupchats +Date: 2015-09-12 13:58 +Author: Jfreegman +Category: development, groupchats, testing +Status: published + +With the [new +groupchats](https://github.com/JFreegman/toxcore/blob/new_groupchats/docs/Group-Chats.md) almost +complete I thought it was time for another big testing session, and this +time I decided I would take you all along for the roller coaster ride of +fun. Before you read any further, I should warn that this is a technical +post geared towards the programmers and developers in the crowd. If +protocols and C code aren't your thing, [click +here](https://www.youtube.com/watch?v=KMFOVSWn0mI). + +For those who don't know [what fuzzing +is](https://www.youtube.com/watch?v=Xnwodi2CBws), it's a form of random +code testing. The idea is simple: feed your program random/malformed +data and wait for it to crash; gather crash info, fix the crash, and +repeat (or log the crash and keep going). The purpose of this type of +testing is to explore the deep dark corners of the state space in order +to catch bugs that normal usage or unit testing would almost certainly +miss. These types of bugs—particularly in memory unsafe languages such +as C—can lead to subtle vulnerabilities that leave the door open for +exploitation. + +There are different levels of fuzzing ranging from dumb to smart, which +explore different aspects and depths of the application protocol. An +example of the dumbest form of fuzzing would be to fill a packet with +completely random data and send it to the packet handler. Dumb fuzzing +theoretically guarantees 100% code coverage given enough time, but in +reality the universe will probably end before it ever gets past the +first hash check. Conversely, smart fuzzing creates valid data and +modifies/corrupts it to varying degrees. This ends up covering a smaller +state space, but in practice has much greater code coverage, and is +generally more useful for all but the simplest of programs. + +I chose only to use two levels, where level-1 is dumb-ish and level-2 is +smart-ish. Something highly complex like a compiler or a web browser +might require 6 or 7 levels or even more, but the groupchat protocol is +pretty simple and more straightforward by comparison. In hindsight, a +3rd level might be warranted, but each added level greatly increases the +amount of work, and I'm not convinced that it would be worth the effort, +as even level-1 fuzzing has satisfactory code coverage much of the time. + +Before going any further, it would be helpful to understand the +structure of a Tox groupchat packet: + +** \[ IP/UDP | Header 1 | Header 2 | App data \]** + +Zooming in to the three sections we care about: + +Header 1: **\[ Packet ID (1 b) | Chat ID hash (4 b) | Sender PK +(32 b) | nonce (24 b) \]** + +Header 2: **\[ Random padding (0-8 b) | Group packet type (1 b) + \]** + +App data: **\[ Sender pub-key hash (4 b) | payload (0-? b) \]** + +The first header is a plain-text section comprised of integrity checks; +if any of these are invalid the packet will be discarded. The second +header, which is encrypted along with the rest of the packet, mitigates +certain types of length-based packet analysis with padding, and tells us +what higher-level function needs to be done. Due to the very simple +nature of these headers and the straightforward way in which they're +handled, unit testing and manual inspection would be better suited for +this section of the code. Instead, I skipped all that and focused my +efforts on the app data, or more specifically, the payload. + +Level-1 targets everything starting after the sender pub-key hash in the +app data. The code looks like +[this](https://gist.github.com/JFreegman/7240bd05519876a7f772). What it +does is create a data buffer containing a valid public-key hash and a +bunch of random data as the payload (this is the app data section of the +packet, which is always created before adding the headers). Then the +packet is sent *n* times to each peer in the group, where *n* is the +number of different packet types that we want to test. If the for loops +in **fuzz\_send\_group\_packet()** confuse you, check out the +**GROUP\_PACKET\_TYPE** and **GROUP\_BROADCAST\_TYPE** enumerators in +the [group\_chats.h +file](https://github.com/JFreegman/toxcore/blob/new_groupchats/toxcore/group_chats.h#L119). + +A few of the packet types only have a single data field in their +payload, so for them this is actually close to the highest possible +level of fuzzing. An example of this would be normal text messages, +where the entire payload is the message itself. On the other hand, some +of the packet types have numerous fields with sensitive parsing +operations tied to them, and these are the ones that require us to go a +bit deeper. For example, the sync response payload looks like this: + +**\[ num\_peers | peer\_data\_1 | peer\_data\_2 | etc. \]** + +What makes it complicated is the fact that peer data is itself just +another series of data chunks of varied sizes (a protocol within a +protocol), all of which must be treated as untrusted and potentially +malicious. What happens if num\_peers doesn't reflect the actual number +of peers being sent? What happens if critical parts of the peer data +gets corrupted, such as the nick length? What happens if the packet is +too small? + +To answer these questions, we move to level-2 smart-ish fuzzing. I first +need to create a valid sync response packet. There are different ways +you could do this, but I chose the path of least resistance and +copy-pasted most of [the +code](https://gist.github.com/JFreegman/9e317cc073f20e7be88e) for +creating sync responses, adjusting things where needed. Most of that +code isn't too relevant here; the interesting part is the call +to** fuzz\_gc\_packet()** at the bottom. Go ahead and [take +a look](https://gist.github.com/JFreegman/cc08d2f68a48bc34ff57) at +what's inside that function, as it's the most critical part of the +smart-fuzzing code, and differs quite a bit from the way level-1 +randomizes packets. + +Rather than randomizing every byte in the payload, bytes are randomized +with a probability *f*, called the fuzz-factor, with use of the +**fuzz\_this\_byte()** function. This is because I want to test packets +with different levels of corruption. Having *f* constantly cycle with +clock ticks means I can test payloads with a level of corruption ranging +from 0 bytes to the entire thing. In addition to randomizing bytes, I +sometimes also modify the data length. This tests bounds checking, +although it's only useful for packet types that don't have a strict +length requirement. For example, we would want to do this for sync +responses because the sync response handler only checks the lower bound +with the clause: if (length <= sizeof(uint32\_t)). + +Once I finished the tedious task of re-creating all the message sender +functions in fuzz-form and made sure everything was working properly, it +was time to try it out. I re-compiled the code with the [LLVM address +sanitizer](http://clang.llvm.org/docs/AddressSanitizer.html) enabled, +and ran three concurrent instances (that is, three peers in one group, +all spamming each other with fuzzed packets). I would then re-start the +session every time it crashed or critically misbehaved. Some people +might just settle for running it with a debugger attached, but with C +there is no guarantee that invalid memory operations will cause a crash. +The address sanitizer is a much more reliable tool for this purpose +(though it has its own downsides that make debugging more difficult). + +I ended up discovering a total of four bugs all within quick succession, + two of which were memory related ([fix +1](https://github.com/JFreegman/toxcore/commit/1732318e05c8e3ddad67411eb59de999ee62db0d)), +and two of which were behaviour related ([fix +2](https://github.com/JFreegman/toxcore/commit/689ea6091ff2784c048380e22a8340b0c70f605e)). +After gaining confidence that there were no more 'easy' bugs, I left the +three instances running overnight while I slept, and found everything +running perfectly when I woke up. Eight hours sounds like a lot of time, +but in the world of fuzzing it's only about average. It's common for +people to leave their fuzzers running over the weekend, or even for +weeks at a time, although it's highly context-dependent. + +With that said, I think eight hours without a crash indicates a good +deal of robustness (that or my fuzzer isn't very good; hopefully the +former). While I still can't guarantee that my code is perfectly rock +solid, and will not stop testing here, I have much more confidence in it +now as we get close to merging the new groupchats into Toxcore's master +branch. + +If anyone has any suggestions, constructive criticism, or spots any +errors, I'd love to hear about it in the comments. Happy Toxing! diff --git a/content/blog/2015-09-12_fuzzing-the-new-groupchats.en.md b/content/blog/2015-09-12_fuzzing-the-new-groupchats.en.md new file mode 100644 index 0000000..a3a5c63 --- /dev/null +++ b/content/blog/2015-09-12_fuzzing-the-new-groupchats.en.md @@ -0,0 +1,159 @@ +Title: Fuzzing The New Groupchats +Date: 2015-09-12 13:58 +Author: Jfreegman +Category: development, groupchats, testing +Status: published + +With the [new +groupchats](https://github.com/JFreegman/toxcore/blob/new_groupchats/docs/Group-Chats.md) almost +complete I thought it was time for another big testing session, and this +time I decided I would take you all along for the roller coaster ride of +fun. Before you read any further, I should warn that this is a technical +post geared towards the programmers and developers in the crowd. If +protocols and C code aren't your thing, [click +here](https://www.youtube.com/watch?v=KMFOVSWn0mI). + +For those who don't know [what fuzzing +is](https://www.youtube.com/watch?v=Xnwodi2CBws), it's a form of random +code testing. The idea is simple: feed your program random/malformed +data and wait for it to crash; gather crash info, fix the crash, and +repeat (or log the crash and keep going). The purpose of this type of +testing is to explore the deep dark corners of the state space in order +to catch bugs that normal usage or unit testing would almost certainly +miss. These types of bugs—particularly in memory unsafe languages such +as C—can lead to subtle vulnerabilities that leave the door open for +exploitation. + +There are different levels of fuzzing ranging from dumb to smart, which +explore different aspects and depths of the application protocol. An +example of the dumbest form of fuzzing would be to fill a packet with +completely random data and send it to the packet handler. Dumb fuzzing +theoretically guarantees 100% code coverage given enough time, but in +reality the universe will probably end before it ever gets past the +first hash check. Conversely, smart fuzzing creates valid data and +modifies/corrupts it to varying degrees. This ends up covering a smaller +state space, but in practice has much greater code coverage, and is +generally more useful for all but the simplest of programs. + +I chose only to use two levels, where level-1 is dumb-ish and level-2 is +smart-ish. Something highly complex like a compiler or a web browser +might require 6 or 7 levels or even more, but the groupchat protocol is +pretty simple and more straightforward by comparison. In hindsight, a +3rd level might be warranted, but each added level greatly increases the +amount of work, and I'm not convinced that it would be worth the effort, +as even level-1 fuzzing has satisfactory code coverage much of the time. + +Before going any further, it would be helpful to understand the +structure of a Tox groupchat packet: + +** \[ IP/UDP | Header 1 | Header 2 | App data \]** + +Zooming in to the three sections we care about: + +Header 1: **\[ Packet ID (1 b) | Chat ID hash (4 b) | Sender PK +(32 b) | nonce (24 b) \]** + +Header 2: **\[ Random padding (0-8 b) | Group packet type (1 b) + \]** + +App data: **\[ Sender pub-key hash (4 b) | payload (0-? b) \]** + +The first header is a plain-text section comprised of integrity checks; +if any of these are invalid the packet will be discarded. The second +header, which is encrypted along with the rest of the packet, mitigates +certain types of length-based packet analysis with padding, and tells us +what higher-level function needs to be done. Due to the very simple +nature of these headers and the straightforward way in which they're +handled, unit testing and manual inspection would be better suited for +this section of the code. Instead, I skipped all that and focused my +efforts on the app data, or more specifically, the payload. + +Level-1 targets everything starting after the sender pub-key hash in the +app data. The code looks like +[this](https://gist.github.com/JFreegman/7240bd05519876a7f772). What it +does is create a data buffer containing a valid public-key hash and a +bunch of random data as the payload (this is the app data section of the +packet, which is always created before adding the headers). Then the +packet is sent *n* times to each peer in the group, where *n* is the +number of different packet types that we want to test. If the for loops +in **fuzz\_send\_group\_packet()** confuse you, check out the +**GROUP\_PACKET\_TYPE** and **GROUP\_BROADCAST\_TYPE** enumerators in +the [group\_chats.h +file](https://github.com/JFreegman/toxcore/blob/new_groupchats/toxcore/group_chats.h#L119). + +A few of the packet types only have a single data field in their +payload, so for them this is actually close to the highest possible +level of fuzzing. An example of this would be normal text messages, +where the entire payload is the message itself. On the other hand, some +of the packet types have numerous fields with sensitive parsing +operations tied to them, and these are the ones that require us to go a +bit deeper. For example, the sync response payload looks like this: + +**\[ num\_peers | peer\_data\_1 | peer\_data\_2 | etc. \]** + +What makes it complicated is the fact that peer data is itself just +another series of data chunks of varied sizes (a protocol within a +protocol), all of which must be treated as untrusted and potentially +malicious. What happens if num\_peers doesn't reflect the actual number +of peers being sent? What happens if critical parts of the peer data +gets corrupted, such as the nick length? What happens if the packet is +too small? + +To answer these questions, we move to level-2 smart-ish fuzzing. I first +need to create a valid sync response packet. There are different ways +you could do this, but I chose the path of least resistance and +copy-pasted most of [the +code](https://gist.github.com/JFreegman/9e317cc073f20e7be88e) for +creating sync responses, adjusting things where needed. Most of that +code isn't too relevant here; the interesting part is the call +to** fuzz\_gc\_packet()** at the bottom. Go ahead and [take +a look](https://gist.github.com/JFreegman/cc08d2f68a48bc34ff57) at +what's inside that function, as it's the most critical part of the +smart-fuzzing code, and differs quite a bit from the way level-1 +randomizes packets. + +Rather than randomizing every byte in the payload, bytes are randomized +with a probability *f*, called the fuzz-factor, with use of the +**fuzz\_this\_byte()** function. This is because I want to test packets +with different levels of corruption. Having *f* constantly cycle with +clock ticks means I can test payloads with a level of corruption ranging +from 0 bytes to the entire thing. In addition to randomizing bytes, I +sometimes also modify the data length. This tests bounds checking, +although it's only useful for packet types that don't have a strict +length requirement. For example, we would want to do this for sync +responses because the sync response handler only checks the lower bound +with the clause: if (length <= sizeof(uint32\_t)). + +Once I finished the tedious task of re-creating all the message sender +functions in fuzz-form and made sure everything was working properly, it +was time to try it out. I re-compiled the code with the [LLVM address +sanitizer](http://clang.llvm.org/docs/AddressSanitizer.html) enabled, +and ran three concurrent instances (that is, three peers in one group, +all spamming each other with fuzzed packets). I would then re-start the +session every time it crashed or critically misbehaved. Some people +might just settle for running it with a debugger attached, but with C +there is no guarantee that invalid memory operations will cause a crash. +The address sanitizer is a much more reliable tool for this purpose +(though it has its own downsides that make debugging more difficult). + +I ended up discovering a total of four bugs all within quick succession, + two of which were memory related ([fix +1](https://github.com/JFreegman/toxcore/commit/1732318e05c8e3ddad67411eb59de999ee62db0d)), +and two of which were behaviour related ([fix +2](https://github.com/JFreegman/toxcore/commit/689ea6091ff2784c048380e22a8340b0c70f605e)). +After gaining confidence that there were no more 'easy' bugs, I left the +three instances running overnight while I slept, and found everything +running perfectly when I woke up. Eight hours sounds like a lot of time, +but in the world of fuzzing it's only about average. It's common for +people to leave their fuzzers running over the weekend, or even for +weeks at a time, although it's highly context-dependent. + +With that said, I think eight hours without a crash indicates a good +deal of robustness (that or my fuzzer isn't very good; hopefully the +former). While I still can't guarantee that my code is perfectly rock +solid, and will not stop testing here, I have much more confidence in it +now as we get close to merging the new groupchats into Toxcore's master +branch. + +If anyone has any suggestions, constructive criticism, or spots any +errors, I'd love to hear about it in the comments. Happy Toxing! diff --git a/content/blog/2015-09-21_new-website.de.md b/content/blog/2015-09-21_new-website.de.md new file mode 100644 index 0000000..81e5201 --- /dev/null +++ b/content/blog/2015-09-21_new-website.de.md @@ -0,0 +1,31 @@ +Title: New website? +Date: 2015-09-21 14:18 +Author: installgen2 +Category: Uncategorized +Status: published + +Hey guys, installgen2 here, I've been working a little bit on what I +hope to be Tox's new website one day. Quite a few users have complained +about the current site, for reasons which are listed: + +- Proprietary JS +- Code nobody wants to work on +- Broken scrolling (for a lot of browsers) +- No mobile support +- Design inconsistent with the rest of Tox +- Extremely heavy resource usage +- Everything listed [here](https://github.com/Tox/Tox-Website/issues) +- [This](https://github.com/Tox/Tox-Website/issues/8) issue raises + some points too + +So, as nobody else to my knowledge had started developing a new site, I +started work on one. Unfortunately, I don't have the time or the +experience to continue development on my own, and I need help if I want +to continue. I'm asking everyone with an interest in web-development and +design, to help me out with the new site. + +Anybody interested, please either join our [\#tox-dev IRC channel on +Freenode](https://wiki.tox.chat/users/community#irc?), or contribute +directly to [the repo on +GitHub](https://github.com/installgen2/tox.chat). You can see my current +progress at . Thanks! diff --git a/content/blog/2015-09-21_new-website.en.md b/content/blog/2015-09-21_new-website.en.md new file mode 100644 index 0000000..81e5201 --- /dev/null +++ b/content/blog/2015-09-21_new-website.en.md @@ -0,0 +1,31 @@ +Title: New website? +Date: 2015-09-21 14:18 +Author: installgen2 +Category: Uncategorized +Status: published + +Hey guys, installgen2 here, I've been working a little bit on what I +hope to be Tox's new website one day. Quite a few users have complained +about the current site, for reasons which are listed: + +- Proprietary JS +- Code nobody wants to work on +- Broken scrolling (for a lot of browsers) +- No mobile support +- Design inconsistent with the rest of Tox +- Extremely heavy resource usage +- Everything listed [here](https://github.com/Tox/Tox-Website/issues) +- [This](https://github.com/Tox/Tox-Website/issues/8) issue raises + some points too + +So, as nobody else to my knowledge had started developing a new site, I +started work on one. Unfortunately, I don't have the time or the +experience to continue development on my own, and I need help if I want +to continue. I'm asking everyone with an interest in web-development and +design, to help me out with the new site. + +Anybody interested, please either join our [\#tox-dev IRC channel on +Freenode](https://wiki.tox.chat/users/community#irc?), or contribute +directly to [the repo on +GitHub](https://github.com/installgen2/tox.chat). You can see my current +progress at . Thanks! diff --git a/content/blog/2015-11-03_new-tox-av-api.de.md b/content/blog/2015-11-03_new-tox-av-api.de.md new file mode 100644 index 0000000..a6e3a62 --- /dev/null +++ b/content/blog/2015-11-03_new-tox-av-api.de.md @@ -0,0 +1,24 @@ +Title: New Tox A/V API +Date: 2015-11-03 12:14 +Author: Impyy +Category: Uncategorized +Status: published + +That's right, today is the big day! After months of work, the new API +for Tox A/V has finally been merged into toxcore. + +Changes: + +- A new API, similar to toxcore. +- A better adaptive bit rate algorithm. + +Nothing too surprising for the average user, but great news for +developers. + +The reason for this blog post is the fact that this update will +break the protocol, which means you will have to update your clients. +Most of our main clients are ready and if all goes well you should +receive an update later today. These include: uTox, qTox, Toxic and +Antidote. + +Happy Toxing! diff --git a/content/blog/2015-11-03_new-tox-av-api.en.md b/content/blog/2015-11-03_new-tox-av-api.en.md new file mode 100644 index 0000000..a6e3a62 --- /dev/null +++ b/content/blog/2015-11-03_new-tox-av-api.en.md @@ -0,0 +1,24 @@ +Title: New Tox A/V API +Date: 2015-11-03 12:14 +Author: Impyy +Category: Uncategorized +Status: published + +That's right, today is the big day! After months of work, the new API +for Tox A/V has finally been merged into toxcore. + +Changes: + +- A new API, similar to toxcore. +- A better adaptive bit rate algorithm. + +Nothing too surprising for the average user, but great news for +developers. + +The reason for this blog post is the fact that this update will +break the protocol, which means you will have to update your clients. +Most of our main clients are ready and if all goes well you should +receive an update later today. These include: uTox, qTox, Toxic and +Antidote. + +Happy Toxing! diff --git a/content/blog/2016-02-08_scale-14x-post-mortem.de.md b/content/blog/2016-02-08_scale-14x-post-mortem.de.md new file mode 100644 index 0000000..b4ec493 --- /dev/null +++ b/content/blog/2016-02-08_scale-14x-post-mortem.de.md @@ -0,0 +1,98 @@ +Title: SCaLE 14x Post-Mortem +Date: 2016-02-08 21:18 +Author: zero-one +Category: Uncategorized +Status: published + +For those who aren't aware, The Tox Project was an exhibitor at this +year's [Southern California Linux +Expo](https://www.socallinuxexpo.org/scale/14x), one of the largest +Linux and FOSS-related conventions in the U.S. We were there to spread +awareness of Tox and The Tox Project, and to get some feedback from the +community regarding our work. + +My experience at SCaLE started out with the excellent [Friday morning +keynote](https://www.socallinuxexpo.org/scale/14x/presentations/no-matter-whos-winning-war-general-purpose-computing-youre-losing) +by the EFF's Cory Doctorow (who later dropped by our booth to chat). +Afterward, I went to check out our booth space on the expo floor and set +up. It's an interesting feeling to be setting up your booth with nothing +but some stickers, a laptop, a vinyl banner, and a television, while HP +and Facebook at the neighboring booths are hauling in truckloads of +mainframe servers, custom-built networking switches, and the like to +show off. However, despite our small-fry stature, I think that The Tox +Project did pretty well for itself. + +Over-all, the experience was extremely positive. Many of the expo +attendees that stopped by our booth had already heard of Tox, or had +used it before in some capacity. Everyone had good things to say about +our efforts; the large amount of moral support we received was very +encouraging. Our logo is also apparently very popular; we ran completely +out of our die-cut Tox lock logo stickers, and were left with only 3 +small stacks of our rectangular stickers, so I'm looking forward to +seeing those Tox stickers pasted everywhere! Here are some up-close +pictures of the stickers we brought: + +![Our die-cut Tox lock logo sticker]({filename}static/images/scale-14x-1.jpg) + +![Our die-cut Tox lock logo sticker]({filename}static/images/scale-14x-2.jpg) +Our die-cut Tox lock logo sticker + +One thing was made very clear to me during the expo by attendees that +came to the booth; Tox fills a niche in free software that very +seriously needs filling. There is a need and want for something like Tox +both at home **and** at the workplace by more people than you can count. +Tox has seen some pretty rough times, and isn't yet in the best of +possible shapes, but we have incredible staying power, in large part +because of the widespread desire for a drop-in Skype replacement that +doesn't abuse its end-users. Because of this staying power, we're +improving, and will always continue to do so. + +In addition, a few of the things we already know were made more evident; +Tox is not going to see wide adoption until we solve a few very big +technical problems. Tox needs **distributed** solutions to the +multi-device problem, the name-to-ID mapping problem (currently worked +around with [ToxMe](https://toxme.io/)), and the offline messaging +problem. None of these problems are impossible to solve, they're just +very difficult to do correctly. We've already seen at least one proposal +for a solution, but nothing that we can implement immediately; we need +more manpower for research and implementation. On that note, if you (or +someone you know) are a strong C programmer with experience in +distributed systems, and you're looking for a FOSS project to contribute +to, drop us an email at leadership@tox.chat, and we'll be glad to get +you up to speed. + +There isn't much more for me to fill you in on, with regard to SCaLE. We +spoke to very many people, and I think that we were successful at doing +what we came to do. + +All-in-all, SCaLE has left me refreshed. I'm glad that I'm able to start +this year with a renewed vigor for The Tox Project, and I look forward +to us continuing our mission to enable free and secure exchange of +information via Tox. + +Shout-outs to [Digital Ocean](https://www.digitalocean.com/), +[Snowdrift](https://snowdrift.coop/), [Open Source +Initiative](http://opensource.org/), and all of the other awesome +exhibitors that we got a chance to meet with at SCaLE. And a shout-out +to my good friends *whyt* and *swiss*, for volunteering some of their +time at our booth. + +In case you didn't catch them on our Facebook/Twitter, here are a few +pictures from the event. They include Chuong Vu, an ObjcTox developer, +Greg Mullen (grayhatter), the main developer of uTox, and myself +(zero-one). + +![Setting up the booth before the expo floor opens to the conference-goers]({filename}static/images/scale-14x-3.jpg) +Setting up the booth before the expo floor opens to the conference-goers + +![Chuong Vu (right) and myself (left) getting ready to show off some Tox clients]({filename}static/images/scale-14x-4.jpg) +Chuong Vu (right) and myself (left) getting ready to show off some Tox clients + +![Greg Mullen (left) and Chuong Vu (right) explaining Tox to an expo attendee]({filename}static/images/scale-14x-5.jpg) +Greg Mullen (left) and Chuong Vu (right) explaining Tox to an expo attendee + +![Chuong Vu (near) and Greg Mullen (far) explaining Tox to an expo attendee]({filename}static/images/scale-14x-6.jpg) +Chuong Vu (near) and Greg Mullen (far) explaining Tox to an expo attendee + +![Having a good time at dinner. Pizza and calzones, yum!]({filename}static/images/scale-14x-7.jpg) +Having a good time at dinner. Pizza and calzones, yum! diff --git a/content/blog/2016-02-08_scale-14x-post-mortem.en.md b/content/blog/2016-02-08_scale-14x-post-mortem.en.md new file mode 100644 index 0000000..b4ec493 --- /dev/null +++ b/content/blog/2016-02-08_scale-14x-post-mortem.en.md @@ -0,0 +1,98 @@ +Title: SCaLE 14x Post-Mortem +Date: 2016-02-08 21:18 +Author: zero-one +Category: Uncategorized +Status: published + +For those who aren't aware, The Tox Project was an exhibitor at this +year's [Southern California Linux +Expo](https://www.socallinuxexpo.org/scale/14x), one of the largest +Linux and FOSS-related conventions in the U.S. We were there to spread +awareness of Tox and The Tox Project, and to get some feedback from the +community regarding our work. + +My experience at SCaLE started out with the excellent [Friday morning +keynote](https://www.socallinuxexpo.org/scale/14x/presentations/no-matter-whos-winning-war-general-purpose-computing-youre-losing) +by the EFF's Cory Doctorow (who later dropped by our booth to chat). +Afterward, I went to check out our booth space on the expo floor and set +up. It's an interesting feeling to be setting up your booth with nothing +but some stickers, a laptop, a vinyl banner, and a television, while HP +and Facebook at the neighboring booths are hauling in truckloads of +mainframe servers, custom-built networking switches, and the like to +show off. However, despite our small-fry stature, I think that The Tox +Project did pretty well for itself. + +Over-all, the experience was extremely positive. Many of the expo +attendees that stopped by our booth had already heard of Tox, or had +used it before in some capacity. Everyone had good things to say about +our efforts; the large amount of moral support we received was very +encouraging. Our logo is also apparently very popular; we ran completely +out of our die-cut Tox lock logo stickers, and were left with only 3 +small stacks of our rectangular stickers, so I'm looking forward to +seeing those Tox stickers pasted everywhere! Here are some up-close +pictures of the stickers we brought: + +![Our die-cut Tox lock logo sticker]({filename}static/images/scale-14x-1.jpg) + +![Our die-cut Tox lock logo sticker]({filename}static/images/scale-14x-2.jpg) +Our die-cut Tox lock logo sticker + +One thing was made very clear to me during the expo by attendees that +came to the booth; Tox fills a niche in free software that very +seriously needs filling. There is a need and want for something like Tox +both at home **and** at the workplace by more people than you can count. +Tox has seen some pretty rough times, and isn't yet in the best of +possible shapes, but we have incredible staying power, in large part +because of the widespread desire for a drop-in Skype replacement that +doesn't abuse its end-users. Because of this staying power, we're +improving, and will always continue to do so. + +In addition, a few of the things we already know were made more evident; +Tox is not going to see wide adoption until we solve a few very big +technical problems. Tox needs **distributed** solutions to the +multi-device problem, the name-to-ID mapping problem (currently worked +around with [ToxMe](https://toxme.io/)), and the offline messaging +problem. None of these problems are impossible to solve, they're just +very difficult to do correctly. We've already seen at least one proposal +for a solution, but nothing that we can implement immediately; we need +more manpower for research and implementation. On that note, if you (or +someone you know) are a strong C programmer with experience in +distributed systems, and you're looking for a FOSS project to contribute +to, drop us an email at leadership@tox.chat, and we'll be glad to get +you up to speed. + +There isn't much more for me to fill you in on, with regard to SCaLE. We +spoke to very many people, and I think that we were successful at doing +what we came to do. + +All-in-all, SCaLE has left me refreshed. I'm glad that I'm able to start +this year with a renewed vigor for The Tox Project, and I look forward +to us continuing our mission to enable free and secure exchange of +information via Tox. + +Shout-outs to [Digital Ocean](https://www.digitalocean.com/), +[Snowdrift](https://snowdrift.coop/), [Open Source +Initiative](http://opensource.org/), and all of the other awesome +exhibitors that we got a chance to meet with at SCaLE. And a shout-out +to my good friends *whyt* and *swiss*, for volunteering some of their +time at our booth. + +In case you didn't catch them on our Facebook/Twitter, here are a few +pictures from the event. They include Chuong Vu, an ObjcTox developer, +Greg Mullen (grayhatter), the main developer of uTox, and myself +(zero-one). + +![Setting up the booth before the expo floor opens to the conference-goers]({filename}static/images/scale-14x-3.jpg) +Setting up the booth before the expo floor opens to the conference-goers + +![Chuong Vu (right) and myself (left) getting ready to show off some Tox clients]({filename}static/images/scale-14x-4.jpg) +Chuong Vu (right) and myself (left) getting ready to show off some Tox clients + +![Greg Mullen (left) and Chuong Vu (right) explaining Tox to an expo attendee]({filename}static/images/scale-14x-5.jpg) +Greg Mullen (left) and Chuong Vu (right) explaining Tox to an expo attendee + +![Chuong Vu (near) and Greg Mullen (far) explaining Tox to an expo attendee]({filename}static/images/scale-14x-6.jpg) +Chuong Vu (near) and Greg Mullen (far) explaining Tox to an expo attendee + +![Having a good time at dinner. Pizza and calzones, yum!]({filename}static/images/scale-14x-7.jpg) +Having a good time at dinner. Pizza and calzones, yum! diff --git a/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.de.md b/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.de.md new file mode 100644 index 0000000..5ede94c --- /dev/null +++ b/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.de.md @@ -0,0 +1,20 @@ +Title: Tox Endorses Donald Trump for President. +Date: 2016-04-01 20:19 +Author: irungentoo +Category: Uncategorized +Status: published + +https://www.youtube.com/watch?v=Ia5uskvvGRs + +The Tox project is proud to endorse Donald Trump for president of the +United States. + +We believe that a Trump presidency will lead to an increased amount of +Tox users and that it will help the privacy movement become much +stronger than it is now. + +If you support privacy we ask that you vote for Donald Trump and do +everything you can to make him become the next president. President +Trump will help make privacy software great again. + +Trump 2016 - because together we can make privacy great again. diff --git a/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.en.md b/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.en.md new file mode 100644 index 0000000..5ede94c --- /dev/null +++ b/content/blog/2016-04-01_tox-endorses-donald-trump-for-president.en.md @@ -0,0 +1,20 @@ +Title: Tox Endorses Donald Trump for President. +Date: 2016-04-01 20:19 +Author: irungentoo +Category: Uncategorized +Status: published + +https://www.youtube.com/watch?v=Ia5uskvvGRs + +The Tox project is proud to endorse Donald Trump for president of the +United States. + +We believe that a Trump presidency will lead to an increased amount of +Tox users and that it will help the privacy movement become much +stronger than it is now. + +If you support privacy we ask that you vote for Donald Trump and do +everything you can to make him become the next president. President +Trump will help make privacy software great again. + +Trump 2016 - because together we can make privacy great again. diff --git a/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.de.md b/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.de.md new file mode 100644 index 0000000..815113e --- /dev/null +++ b/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.de.md @@ -0,0 +1,44 @@ +Title: Update: New group chats, multi-device, and more! +Date: 2016-06-07 08:05 +Author: Jfreegman +Category: Uncategorized +Status: published + +Hey everyone! It's been a while since our last update, so we'd like to +get everyone up to speed on what's been going on in terms of Toxcore +development and community happenings. + +One of the most discussed topics in the Tox community over the past few +months has been the release of the new group chats. Unfortunately, there +is still no ETA. I finished writing the code base about 6 months ago and +they've been available for testing for some time via my new groupchats +[branch](https://github.com/JFreegman/toxcore). However, it's still +missing one crucial thing: TCP support. The new group chats cannot be +merged without TCP-DHT support in the core, which is currently being +worked on in a private branch by the lead core developer, irungentoo. +The latest word is that DHT is currently working over TCP, but he's +still having issues with bugs and failing tests. We know how eager +everyone is to finally be able to try out the new group chats, and we +want the community to know that work is being done and progress is being +made. + +In other news, [Grayhatter](https://github.com/grayhatter), along with +the support of [Tux3](https://github.com/tux3), is working on another +widely requested feature for +Toxcore—[Multi-device](https://github.com/GrayHatter/toxcore/tree/multi-device) support. It's +still in a very early, hardly-working stage of development, but if you +like the idea of testing extremely buggy code that may or may not delete +your profile, you can try the [Multi-device +version](https://github.com/GrayHatter/uTox/tree/multidevice) of *µTox*. +**(Note: backup your save.tox profile first.)** + +Finally, we would like to offer a heartfelt thank you to +[LittleVulpix](https://github.com/littlevulpix) for stepping up to the +plate and taking over [toxme.io](https://toxme.io) after its original +owner no longer had the ability to maintain the service. Additionally, +we want to thank [Encrypt](https://github.com/Encrypt), who created a +packaging script, and with the help of Tux3 has adjusted the script to +work on our build infrastructure. + +That's it for now, but hopefully we'll have some more announcements for +you in the near future. Happy Toxing! diff --git a/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.en.md b/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.en.md new file mode 100644 index 0000000..815113e --- /dev/null +++ b/content/blog/2016-06-07_update-new-group-chats-multi-device-and-more.en.md @@ -0,0 +1,44 @@ +Title: Update: New group chats, multi-device, and more! +Date: 2016-06-07 08:05 +Author: Jfreegman +Category: Uncategorized +Status: published + +Hey everyone! It's been a while since our last update, so we'd like to +get everyone up to speed on what's been going on in terms of Toxcore +development and community happenings. + +One of the most discussed topics in the Tox community over the past few +months has been the release of the new group chats. Unfortunately, there +is still no ETA. I finished writing the code base about 6 months ago and +they've been available for testing for some time via my new groupchats +[branch](https://github.com/JFreegman/toxcore). However, it's still +missing one crucial thing: TCP support. The new group chats cannot be +merged without TCP-DHT support in the core, which is currently being +worked on in a private branch by the lead core developer, irungentoo. +The latest word is that DHT is currently working over TCP, but he's +still having issues with bugs and failing tests. We know how eager +everyone is to finally be able to try out the new group chats, and we +want the community to know that work is being done and progress is being +made. + +In other news, [Grayhatter](https://github.com/grayhatter), along with +the support of [Tux3](https://github.com/tux3), is working on another +widely requested feature for +Toxcore—[Multi-device](https://github.com/GrayHatter/toxcore/tree/multi-device) support. It's +still in a very early, hardly-working stage of development, but if you +like the idea of testing extremely buggy code that may or may not delete +your profile, you can try the [Multi-device +version](https://github.com/GrayHatter/uTox/tree/multidevice) of *µTox*. +**(Note: backup your save.tox profile first.)** + +Finally, we would like to offer a heartfelt thank you to +[LittleVulpix](https://github.com/littlevulpix) for stepping up to the +plate and taking over [toxme.io](https://toxme.io) after its original +owner no longer had the ability to maintain the service. Additionally, +we want to thank [Encrypt](https://github.com/Encrypt), who created a +packaging script, and with the help of Tux3 has adjusted the script to +work on our build infrastructure. + +That's it for now, but hopefully we'll have some more announcements for +you in the near future. Happy Toxing! diff --git a/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.de.md b/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.de.md new file mode 100644 index 0000000..dedba68 --- /dev/null +++ b/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.de.md @@ -0,0 +1,207 @@ +Title: Update: New client, Xenial packages, Tox in Google Play, Toxcore fork and more! +Date: 2016-08-26 22:38 +Author: nurupo +Category: development, groupchats +Status: published + +Hello everyone! It's been more than two months since the last update and +quite a few things have happened since then, so an update is due. + +Website +------- + +A new client has been added to our website -- +[Toxygen](https://tox.chat/clients.html). It's written in python and +uses Qt for its UI. Give it a try and see if you like it. You can get it +for Windows and Linux from [Toxygen's Releases +page](https://github.com/toxygen-project/toxygen/releases). We also +provide Debian and Ubuntu packages for it in our nightly package +repository. + +Packaging +--------- + +Thanks to Encrypt's and tux3's efforts, we now provide packages for +Ubuntu Xenial. As of writing this, the following client packages are +available in nightly Xenial: Toxic, Toxygen and uTox. + +New packages were added to our package repository: uTox, Ricin and +Toxygen. While we did package uTox before, it was just a static binary, +whereas now we have proper shared binaries made for target +distributions. Ricin is currently available only in the stable +repository, but should soon also be available in the nightly. + +If you have been following qTox blog -- and yes, qTox got its +[blog](https://qtox.github.io/blog), we recommend you follow it if you +are a qTox user -- you should know that [qTox has moved from +distributing Linux packages through our packaging infrastructure to +using openSUSE's Open Build Service (OBS) +platform](https://qtox.github.io/blog/2016/08/10/Hello-World.html), +mainly as OBS allows to create packages for more Linux flavors than just +Debian and Ubuntu, such as Fedora, openSUSE, CentOS and a few more. +Because of this, tux3, the main qTox developer, has stopped maintaining +qTox Linux packages in our package repository, but he is against +removing them just yet to allow for smoother transition of users to OBS. +Encrypt, the other packaging enthusiast, has said that he is willing to +maintain qTox packages in our package repository in tux3's stead, which +tux3 is not against, and he will look into adding support for .rpm +packages (used by Fedora, openSUSE, CentOS, etc.) to our infrastructure. +Packaging is a surprisingly hard and arcane process, so if you have +experience with creating proper .rpm packages in target distribution's +chroots, we could use some help -- [please email +Encrypt](mailto:encrypt@encrypt-tips.tk?subject=Help%20with%20rpm%20packaging&cc=infrastructure@tox.chat). + +Using Tox package repository +---------------------------- + +Just as a reminder, here are instructions on how to get our packages on +Debian and Ubuntu systems. + +We currently support Debian Jessie (8/stable), Debian Stretch +(9/testing), Debian Sid (unstable), Ubuntu Vivid (15.04), Ubuntu Wily +(15.10) and Ubuntu Xenial (16.04 LTS), i386 and amd64 architectures. To +add our package repository, run the following commands, replacing +`TRACK` with either `stable` or `nightly` and replacing `RELEASE` with +one of `jessie`, `stretch`, `sid`, `vivid`, `wily` or `xenial`, +appropriate for your Debian/Ubuntu release. Packages in the stable track +are generally updated whenever a client releases a new version, and +packages in the nightly track are updated once a day with the most +recent development progress, if any. + +`echo "deb https://pkg.tox.chat/debian TRACK RELEASE" | sudo tee /etc/apt/sources.list.d/tox.list wget -qO - https://pkg.tox.chat/debian/pkg.gpg.key | sudo apt-key add - sudo apt-get install apt-transport-https sudo apt-get update # List all client packages available grep -h 'Package: ' /var/lib/apt/lists/pkg.tox.chat* | grep -v ' lib'` + +There is also a special `RELEASE` called `release` available, which +provides statically built versions of some of the clients. It's not very +well maintained, it's there mostly for historic reasons, as this was the +very first release name we had in our package repository and we +advertised it to users. If you are on one of the supported Debian/Ubuntu +releases mentioned above but you use the `release` release, we advise to +switch to the release appropriate for your Debian/Ubuntu version. + +In the future we plan on making nightly packages to be updated as soon +as developers push new code for them, which might happen more frequently +than once a day. We also plan on dropping Ubuntu Vivid and Ubuntu Wily +support at some point, as [those Ubuntu releases have reached their end +of life](https://wiki.ubuntu.com/Releases), and adding support for +Ubuntu Yakkety. + +Android +------- + +Antox got [published on Google +Play](https://play.google.com/store/apps/details?id=chat.tox.antox). +Previously Antox was available only though our [F-Droid +repo](https://pkg.tox.chat/fdroid/repo), [Google Play +testing](https://play.google.com/apps/testing/chat.tox.antox) and as a +[direct APK download](https://pkg.tox.chat/fdroid/repo/antox.apk), but +now everyone can easily find and download it through Google Play. While +we believe that it might be a bit too early to make it publicly +available for everyone, given that Toxcore is not optimized for mobile +yet: it uses **a lot** of data and keeps CPU busy, resulting in +increased battery usage, which might turn people away from Tox, the +Antox developer decided that it's the perfect time to publicly release +it, so here we have it. Install it, test it and report any issues to +[Antox issue tracker](https://github.com/Antox/Antox/issues). + +Shockingly enough, uTox also got [published on Google +Play](https://play.google.com/store/apps/details?id=tox.client.utox). +uTox is a native Linux application, not an Android application, made to +run on Android. As such, you can expect it having UI different to what +regular Android applications have, to the point that it might be not +very usable. It's surprising to see it being released on Google Play, as +uTox for Android was created as a joke, just to prove that you indeed +can run it on Android, it wasn't supposed to be used by anyone. You can +give it a try if you feel adventurous enough, and report bugs to [uTox +issue tracker](https://github.com/GrayHatter/uTox/issues), but we'd +suggest waiting for uTox to be properly ported on Android as an Android +application, rather than a generic Linux application. + +The story goes that Antox developer didn't want to publish Antox on +Google Play until Toxcore becomes more mobile friendly, so the uTox +developer published uTox to Google Play just to provoke Antox developer +publishing Antox. Such mind games our developers play with each other. + +Toxcore +------- + +Toxcore's developer, irungentoo, has been very busy lately and unable to +find time to work on Toxcore. Because any change to Toxcore should be +first reviewed and approved by irungentoo, as he is the only one who can +merge changes, Toxcore development has been stalled for some time now. +To get around this, [a non-hostile Toxcore +fork](https://github.com/TokTok/toxcore) was created by iphy, where the +development is currently ongoing. + +You might have noticed that the fork was created in [TokTok GitHub +organization](https://github.com/TokTok). What is TokTok? TokTok +initially was one of [Google Summer of Code 2015 +projects](https://www.google-melange.com/archive/gsoc/2015/orgs/tox) +mentored by iphy, specifically it was the [New Android Client +project](https://wiki.tox.chat/developers/gsoc/2015/ideas#new_android_client) +([GitHub repository](https://github.com/iphydf/toktok)). iphy has +[extended the idea since then +greatly](https://toktok.github.io/index.html), to the point of [making +it a distributed storage and computing +platform](https://toktok.github.io/vision.html), but the fact that it's +still built on top of Toxcore remains unchanged. Why is the new Toxcore +fork in the TokTok GitHub organization? iphy was quick on forking +Toxcore, setting up automated testing and review system, opening bug +reports and adding code contributions, so that before we could even get +iphy to explain what the fork is about and decide whether we should +support it and move it to the [Tox GitHub +organization](https://github.com/Tox), it has already became problematic +to move it to Tox organization because everything would need to be +re-setup again, so we just left it there, at least for now. We might +move it to the Tox GitHub organization later, but for now we don't +really care where it is, what we care is improving Toxcore. + +The current goal that we work towards in the forked Toxcore is to test +whether Toxcore does what the Tox specification says it should be doing. +Since the Tox specification was written after the Toxcore implementation +was made, not the other way around, Toxcore currently has no +specification-based tests. Having a specification testing framework +would allow us to test Toxcore and any possible future Tox +implementation against the claims made in the Tox specification, which +also would allow for an easy way of extending the Tox specification and +having those extensions tested. This goal also would allow us to get +more familiar with Toxcore codebase, as previously only irungentoo had a +good knowledge of it. After the specification-based testing will be +complete and we become familiar with Toxcore codebase, we will be able +to proceed with including new features into the Tox specification and +implementing them. + +Multidevice +----------- + +Multidevice support is not yet complete, [Grayhatter and several other +contributors are still working on +it](https://github.com/GrayHatter/toxcore/tree/multi-device). Some of +the things that need to be done include support of synchronization of +video and audio calls, file transfers and friend deletion actions. + +New group chats +--------------- + +New group chat support is currently not being worked on by anyone. As +you might have read from [the previous update blog +post]({filename}2016-06-07_update-new-group-chats-multi-device-and-more.en.md), +the new group chats are almost fully implemented in JFreegman's Toxcore +fork, the only thing needed for them to work properly is the TCP-DHT +support by Toxcore. Irungentoo has said that he will work on adding +TCP-DHT to Toxcore, but as he has been busy, he never got to adding +TCP-DHT to Toxcore and we don't know when he will have time to do that. +Also, because the current goal of the Toxcore fork is to be fully tested +against Tox specification, and both TCP-DHT and the new group chat are +not (yet) part of the specification, we can't implement them before we +are done with the testing, as implementing them would make Toxcore +behave in a way that is not conforming with the current Tox +specification. For now we are trying to avoid modifying Toxcore +behavior, until we are done with the specification-based tests. We +believe that with irungentoo being less active, having +specification-based tests and good understanding of Toxcore is a good +investment of our time before we move to implementing other features, +such as TCP-DHT for the new group chat, so don't be upset if your +favorite feature didn't make it in, we are slowly but steadily working +on it. + +That's all for now, until the next time! diff --git a/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md b/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md new file mode 100644 index 0000000..dedba68 --- /dev/null +++ b/content/blog/2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md @@ -0,0 +1,207 @@ +Title: Update: New client, Xenial packages, Tox in Google Play, Toxcore fork and more! +Date: 2016-08-26 22:38 +Author: nurupo +Category: development, groupchats +Status: published + +Hello everyone! It's been more than two months since the last update and +quite a few things have happened since then, so an update is due. + +Website +------- + +A new client has been added to our website -- +[Toxygen](https://tox.chat/clients.html). It's written in python and +uses Qt for its UI. Give it a try and see if you like it. You can get it +for Windows and Linux from [Toxygen's Releases +page](https://github.com/toxygen-project/toxygen/releases). We also +provide Debian and Ubuntu packages for it in our nightly package +repository. + +Packaging +--------- + +Thanks to Encrypt's and tux3's efforts, we now provide packages for +Ubuntu Xenial. As of writing this, the following client packages are +available in nightly Xenial: Toxic, Toxygen and uTox. + +New packages were added to our package repository: uTox, Ricin and +Toxygen. While we did package uTox before, it was just a static binary, +whereas now we have proper shared binaries made for target +distributions. Ricin is currently available only in the stable +repository, but should soon also be available in the nightly. + +If you have been following qTox blog -- and yes, qTox got its +[blog](https://qtox.github.io/blog), we recommend you follow it if you +are a qTox user -- you should know that [qTox has moved from +distributing Linux packages through our packaging infrastructure to +using openSUSE's Open Build Service (OBS) +platform](https://qtox.github.io/blog/2016/08/10/Hello-World.html), +mainly as OBS allows to create packages for more Linux flavors than just +Debian and Ubuntu, such as Fedora, openSUSE, CentOS and a few more. +Because of this, tux3, the main qTox developer, has stopped maintaining +qTox Linux packages in our package repository, but he is against +removing them just yet to allow for smoother transition of users to OBS. +Encrypt, the other packaging enthusiast, has said that he is willing to +maintain qTox packages in our package repository in tux3's stead, which +tux3 is not against, and he will look into adding support for .rpm +packages (used by Fedora, openSUSE, CentOS, etc.) to our infrastructure. +Packaging is a surprisingly hard and arcane process, so if you have +experience with creating proper .rpm packages in target distribution's +chroots, we could use some help -- [please email +Encrypt](mailto:encrypt@encrypt-tips.tk?subject=Help%20with%20rpm%20packaging&cc=infrastructure@tox.chat). + +Using Tox package repository +---------------------------- + +Just as a reminder, here are instructions on how to get our packages on +Debian and Ubuntu systems. + +We currently support Debian Jessie (8/stable), Debian Stretch +(9/testing), Debian Sid (unstable), Ubuntu Vivid (15.04), Ubuntu Wily +(15.10) and Ubuntu Xenial (16.04 LTS), i386 and amd64 architectures. To +add our package repository, run the following commands, replacing +`TRACK` with either `stable` or `nightly` and replacing `RELEASE` with +one of `jessie`, `stretch`, `sid`, `vivid`, `wily` or `xenial`, +appropriate for your Debian/Ubuntu release. Packages in the stable track +are generally updated whenever a client releases a new version, and +packages in the nightly track are updated once a day with the most +recent development progress, if any. + +`echo "deb https://pkg.tox.chat/debian TRACK RELEASE" | sudo tee /etc/apt/sources.list.d/tox.list wget -qO - https://pkg.tox.chat/debian/pkg.gpg.key | sudo apt-key add - sudo apt-get install apt-transport-https sudo apt-get update # List all client packages available grep -h 'Package: ' /var/lib/apt/lists/pkg.tox.chat* | grep -v ' lib'` + +There is also a special `RELEASE` called `release` available, which +provides statically built versions of some of the clients. It's not very +well maintained, it's there mostly for historic reasons, as this was the +very first release name we had in our package repository and we +advertised it to users. If you are on one of the supported Debian/Ubuntu +releases mentioned above but you use the `release` release, we advise to +switch to the release appropriate for your Debian/Ubuntu version. + +In the future we plan on making nightly packages to be updated as soon +as developers push new code for them, which might happen more frequently +than once a day. We also plan on dropping Ubuntu Vivid and Ubuntu Wily +support at some point, as [those Ubuntu releases have reached their end +of life](https://wiki.ubuntu.com/Releases), and adding support for +Ubuntu Yakkety. + +Android +------- + +Antox got [published on Google +Play](https://play.google.com/store/apps/details?id=chat.tox.antox). +Previously Antox was available only though our [F-Droid +repo](https://pkg.tox.chat/fdroid/repo), [Google Play +testing](https://play.google.com/apps/testing/chat.tox.antox) and as a +[direct APK download](https://pkg.tox.chat/fdroid/repo/antox.apk), but +now everyone can easily find and download it through Google Play. While +we believe that it might be a bit too early to make it publicly +available for everyone, given that Toxcore is not optimized for mobile +yet: it uses **a lot** of data and keeps CPU busy, resulting in +increased battery usage, which might turn people away from Tox, the +Antox developer decided that it's the perfect time to publicly release +it, so here we have it. Install it, test it and report any issues to +[Antox issue tracker](https://github.com/Antox/Antox/issues). + +Shockingly enough, uTox also got [published on Google +Play](https://play.google.com/store/apps/details?id=tox.client.utox). +uTox is a native Linux application, not an Android application, made to +run on Android. As such, you can expect it having UI different to what +regular Android applications have, to the point that it might be not +very usable. It's surprising to see it being released on Google Play, as +uTox for Android was created as a joke, just to prove that you indeed +can run it on Android, it wasn't supposed to be used by anyone. You can +give it a try if you feel adventurous enough, and report bugs to [uTox +issue tracker](https://github.com/GrayHatter/uTox/issues), but we'd +suggest waiting for uTox to be properly ported on Android as an Android +application, rather than a generic Linux application. + +The story goes that Antox developer didn't want to publish Antox on +Google Play until Toxcore becomes more mobile friendly, so the uTox +developer published uTox to Google Play just to provoke Antox developer +publishing Antox. Such mind games our developers play with each other. + +Toxcore +------- + +Toxcore's developer, irungentoo, has been very busy lately and unable to +find time to work on Toxcore. Because any change to Toxcore should be +first reviewed and approved by irungentoo, as he is the only one who can +merge changes, Toxcore development has been stalled for some time now. +To get around this, [a non-hostile Toxcore +fork](https://github.com/TokTok/toxcore) was created by iphy, where the +development is currently ongoing. + +You might have noticed that the fork was created in [TokTok GitHub +organization](https://github.com/TokTok). What is TokTok? TokTok +initially was one of [Google Summer of Code 2015 +projects](https://www.google-melange.com/archive/gsoc/2015/orgs/tox) +mentored by iphy, specifically it was the [New Android Client +project](https://wiki.tox.chat/developers/gsoc/2015/ideas#new_android_client) +([GitHub repository](https://github.com/iphydf/toktok)). iphy has +[extended the idea since then +greatly](https://toktok.github.io/index.html), to the point of [making +it a distributed storage and computing +platform](https://toktok.github.io/vision.html), but the fact that it's +still built on top of Toxcore remains unchanged. Why is the new Toxcore +fork in the TokTok GitHub organization? iphy was quick on forking +Toxcore, setting up automated testing and review system, opening bug +reports and adding code contributions, so that before we could even get +iphy to explain what the fork is about and decide whether we should +support it and move it to the [Tox GitHub +organization](https://github.com/Tox), it has already became problematic +to move it to Tox organization because everything would need to be +re-setup again, so we just left it there, at least for now. We might +move it to the Tox GitHub organization later, but for now we don't +really care where it is, what we care is improving Toxcore. + +The current goal that we work towards in the forked Toxcore is to test +whether Toxcore does what the Tox specification says it should be doing. +Since the Tox specification was written after the Toxcore implementation +was made, not the other way around, Toxcore currently has no +specification-based tests. Having a specification testing framework +would allow us to test Toxcore and any possible future Tox +implementation against the claims made in the Tox specification, which +also would allow for an easy way of extending the Tox specification and +having those extensions tested. This goal also would allow us to get +more familiar with Toxcore codebase, as previously only irungentoo had a +good knowledge of it. After the specification-based testing will be +complete and we become familiar with Toxcore codebase, we will be able +to proceed with including new features into the Tox specification and +implementing them. + +Multidevice +----------- + +Multidevice support is not yet complete, [Grayhatter and several other +contributors are still working on +it](https://github.com/GrayHatter/toxcore/tree/multi-device). Some of +the things that need to be done include support of synchronization of +video and audio calls, file transfers and friend deletion actions. + +New group chats +--------------- + +New group chat support is currently not being worked on by anyone. As +you might have read from [the previous update blog +post]({filename}2016-06-07_update-new-group-chats-multi-device-and-more.en.md), +the new group chats are almost fully implemented in JFreegman's Toxcore +fork, the only thing needed for them to work properly is the TCP-DHT +support by Toxcore. Irungentoo has said that he will work on adding +TCP-DHT to Toxcore, but as he has been busy, he never got to adding +TCP-DHT to Toxcore and we don't know when he will have time to do that. +Also, because the current goal of the Toxcore fork is to be fully tested +against Tox specification, and both TCP-DHT and the new group chat are +not (yet) part of the specification, we can't implement them before we +are done with the testing, as implementing them would make Toxcore +behave in a way that is not conforming with the current Tox +specification. For now we are trying to avoid modifying Toxcore +behavior, until we are done with the specification-based tests. We +believe that with irungentoo being less active, having +specification-based tests and good understanding of Toxcore is a good +investment of our time before we move to implementing other features, +such as TCP-DHT for the new group chat, so don't be upset if your +favorite feature didn't make it in, we are slowly but steadily working +on it. + +That's all for now, until the next time! diff --git a/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.de.md b/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.de.md new file mode 100644 index 0000000..6696700 --- /dev/null +++ b/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.de.md @@ -0,0 +1,127 @@ +Title: Update: Ubuntu Yakkety packages, Tox in App Store and Toxcore updates! +Date: 2016-10-30 10:11 +Author: nurupo +Category: development +Status: published + +Hello everyone! Some of you have requested us to make a status update, +so here we go. + +Packaging +========= + +Quite a bit has happened with Linux packaging this month. + +Packages for Ubuntu Yakkety (16.10) are available. Our packaging team +prepared for the new Ubuntu release beforehand, packaging clients for +Ubuntu Yakkety while it was still in the beta, so all of our clients +were available for Ubuntu Yakkety on the day of its release. + +Packages for Ubuntu Vivid (15.04) and Ubuntu Wily (15.10) were removed. +We have mentioned in [the previous blog +post]({filename}2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md) +that we would like to remove them at some point, as Ubuntu Vivid and +Ubuntu Wily [have reached EOL](https://wiki.ubuntu.com/Releases), and +addition of packages for the new Ubuntu release served as that point. + +Empty package repositories were removed. These repositories existed +because we considered packaging for them at one point, but because of +cross-compilation complexity and lack of required dependencies on older +distribution versions we decided not to package for them. For example, +we didn't have any packages for armel architecture and for Ubuntu Trusty +release. This [caused some +confusion](https://github.com/Tox/tox.chat/issues/101) as some Tox users +would see these package repositories available and add them, thinking +that they contained Tox clients, when in fact they were empty. + +qTox packages were removed from all package repositories. In [the +previous blog +post]({filename}2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md) +we mentioned that [*Encrypt*](https://github.com/Encrypt) was going to +take over the maintenance of qTox packages, but because of personal +reasons he is not able to volunteer as much of his free time as he hoped +he could. We decided that it's a bad idea to serve unmaintained packages +to our users, so we had to remove them. Although there are no more qTox +packages in our https://pkg.tox.chat package repository, you can still +get qTox packages from the [openSUSE Build Service package +repository](https://software.opensuse.org/download.html?project=home%3Aantonbatenev%3Atox&package=qtox), +which [qTox developers advertise as the recommended place to get qTox +packages](https://github.com/qTox/qTox/blob/master/README.md#qtox), and +which is linked on the [Download page](https://tox.chat/download.html) +of our website. + +iOS +=== + +[Antidote](https://antidote.im/), the Tox client for iOS developer by +[*dvor*](https://github.com/dvor), is now [on the App +Store](https://itunes.apple.com/app/antidote-for-tox/id933117605). Get +it, try it out and send your feedback to Antidote's developer by either +writing a review on the App Store or submitting a bug report/feature +request to [the issue +tracker](https://github.com/Antidote-for-Tox/Antidote/issues)! + +Toxcore +======= + +irungentoo/toxcore +------------------ + +[Not much has +happened](https://github.com/irungentoo/toxcore/compare/1fa5887fee6016318d02911f78f3610dd0e0dc7f...dcf2aaa53005060608353b9d66b9917fd7ed18a9) +with [irungentoo/toxcore](https://github.com/irungentoo/toxcore). +Incorrect permissions set by +tox-boostrapd[\[1\]](https://github.com/irungentoo/toxcore/commit/d28f94a2f9d7ddba2bc439ce7cc3160305cedb82) +and bug in LAN discovery +code[\[2\]](https://github.com/irungentoo/toxcore/commit/e6af3a7825e8307a501bc7c3e7b1ff323f081870) +were fixed. A bug in development branch which resulted in a crash of +Toxcore[\[3\]](https://github.com/irungentoo/toxcore/commit/ce60b9cf52dd20aedbe2f07ed29c96663f94c313) +was fixed. + +TokTok/c-toxcore +---------------- + +[A lot of internal +changes](https://github.com/irungentoo/toxcore/compare/755f084e8720b349026c85afbad58954cb7ff1d4...TokTok:de966cdf90843819e2f7287e22ddcb5f95491b18) +were done in [TokTok/c-toxcore](https://github.com/TokTok/c-toxcore) in +order to make it more testable and to improve the code quality in +general. Compliance with the C standard was +improved[\[4\]](https://github.com/TokTok/c-toxcore/pull/96). Callbacks +thoughout Toxcore have become stateless (ToxAv is comign next), which +will help with bindings for the languages with managed +memory[\[5\]](https://github.com/TokTok/c-toxcore/issues/40). ABI +backward compatibility support was improved +[\[6\]](https://github.com/TokTok/c-toxcore/pull/117), +[\[7\]](https://github.com/TokTok/c-toxcore/pull/70/files). Toxcore was +made compatible with C++, allowing us to use C++ compiler to catch some +type casing issues +[\[8\]](https://github.com/TokTok/c-toxcore/pull/143), +[\[9\]](https://github.com/TokTok/c-toxcore/pull/170). The existing test +suite was improved +[\[10\]](https://github.com/irungentoo/toxcore/compare/755f084e8720b349026c85afbad58954cb7ff1d4...TokTok:de966cdf90843819e2f7287e22ddcb5f95491b18). +Group chat API was rewritten to follow the guidelines of the current +API[\[11\]](https://github.com/TokTok/c-toxcore/pull/135). Generally a +lot of other code improvements happened. + +To allow easier transition of clients from irungentoo/toxcore to +TokTok/c-toxcore, [0.0.1 version of TokTok/c-toxcore was +released](https://github.com/TokTok/c-toxcore/releases/tag/v0.0.1), +which would make it possible for clients to support both Toxcores at the +same time. µTox nightly has already transitioned to using +TokTok/c-toxcore, which means that the next release of µTox will be +using TokTok/c-toxcore. Antidote, Antox and qTox also have plans on +switching to TokTok/c-toxcore. + +Support for UPnP and NAT-PMP is coming to Toxcore +[soon](https://github.com/TokTok/c-toxcore/pull/209). +[UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal) +and [NAT-PMP](https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol) +are port forwarding mechanisms, they allow programs to automatically +setup a port forwarding rules on users' routers without users having to +manually do this. This solves the issue of routers not allowing someone +you have not communicated with before to send you data, improving Tox's +networking performance, as the hole punching workaround would not be +needed to get around this anymore. + +That’s all that has happened during last couple months, until the next +update! diff --git a/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.en.md b/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.en.md new file mode 100644 index 0000000..6696700 --- /dev/null +++ b/content/blog/2016-10-30_update-ubuntu-yakkety-packages-tox-in-app-store-and-toxcore-updates.en.md @@ -0,0 +1,127 @@ +Title: Update: Ubuntu Yakkety packages, Tox in App Store and Toxcore updates! +Date: 2016-10-30 10:11 +Author: nurupo +Category: development +Status: published + +Hello everyone! Some of you have requested us to make a status update, +so here we go. + +Packaging +========= + +Quite a bit has happened with Linux packaging this month. + +Packages for Ubuntu Yakkety (16.10) are available. Our packaging team +prepared for the new Ubuntu release beforehand, packaging clients for +Ubuntu Yakkety while it was still in the beta, so all of our clients +were available for Ubuntu Yakkety on the day of its release. + +Packages for Ubuntu Vivid (15.04) and Ubuntu Wily (15.10) were removed. +We have mentioned in [the previous blog +post]({filename}2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md) +that we would like to remove them at some point, as Ubuntu Vivid and +Ubuntu Wily [have reached EOL](https://wiki.ubuntu.com/Releases), and +addition of packages for the new Ubuntu release served as that point. + +Empty package repositories were removed. These repositories existed +because we considered packaging for them at one point, but because of +cross-compilation complexity and lack of required dependencies on older +distribution versions we decided not to package for them. For example, +we didn't have any packages for armel architecture and for Ubuntu Trusty +release. This [caused some +confusion](https://github.com/Tox/tox.chat/issues/101) as some Tox users +would see these package repositories available and add them, thinking +that they contained Tox clients, when in fact they were empty. + +qTox packages were removed from all package repositories. In [the +previous blog +post]({filename}2016-08-26_update-new-client-xenial-packages-tox-in-google-play-toxcore-fork-and-more.en.md) +we mentioned that [*Encrypt*](https://github.com/Encrypt) was going to +take over the maintenance of qTox packages, but because of personal +reasons he is not able to volunteer as much of his free time as he hoped +he could. We decided that it's a bad idea to serve unmaintained packages +to our users, so we had to remove them. Although there are no more qTox +packages in our https://pkg.tox.chat package repository, you can still +get qTox packages from the [openSUSE Build Service package +repository](https://software.opensuse.org/download.html?project=home%3Aantonbatenev%3Atox&package=qtox), +which [qTox developers advertise as the recommended place to get qTox +packages](https://github.com/qTox/qTox/blob/master/README.md#qtox), and +which is linked on the [Download page](https://tox.chat/download.html) +of our website. + +iOS +=== + +[Antidote](https://antidote.im/), the Tox client for iOS developer by +[*dvor*](https://github.com/dvor), is now [on the App +Store](https://itunes.apple.com/app/antidote-for-tox/id933117605). Get +it, try it out and send your feedback to Antidote's developer by either +writing a review on the App Store or submitting a bug report/feature +request to [the issue +tracker](https://github.com/Antidote-for-Tox/Antidote/issues)! + +Toxcore +======= + +irungentoo/toxcore +------------------ + +[Not much has +happened](https://github.com/irungentoo/toxcore/compare/1fa5887fee6016318d02911f78f3610dd0e0dc7f...dcf2aaa53005060608353b9d66b9917fd7ed18a9) +with [irungentoo/toxcore](https://github.com/irungentoo/toxcore). +Incorrect permissions set by +tox-boostrapd[\[1\]](https://github.com/irungentoo/toxcore/commit/d28f94a2f9d7ddba2bc439ce7cc3160305cedb82) +and bug in LAN discovery +code[\[2\]](https://github.com/irungentoo/toxcore/commit/e6af3a7825e8307a501bc7c3e7b1ff323f081870) +were fixed. A bug in development branch which resulted in a crash of +Toxcore[\[3\]](https://github.com/irungentoo/toxcore/commit/ce60b9cf52dd20aedbe2f07ed29c96663f94c313) +was fixed. + +TokTok/c-toxcore +---------------- + +[A lot of internal +changes](https://github.com/irungentoo/toxcore/compare/755f084e8720b349026c85afbad58954cb7ff1d4...TokTok:de966cdf90843819e2f7287e22ddcb5f95491b18) +were done in [TokTok/c-toxcore](https://github.com/TokTok/c-toxcore) in +order to make it more testable and to improve the code quality in +general. Compliance with the C standard was +improved[\[4\]](https://github.com/TokTok/c-toxcore/pull/96). Callbacks +thoughout Toxcore have become stateless (ToxAv is comign next), which +will help with bindings for the languages with managed +memory[\[5\]](https://github.com/TokTok/c-toxcore/issues/40). ABI +backward compatibility support was improved +[\[6\]](https://github.com/TokTok/c-toxcore/pull/117), +[\[7\]](https://github.com/TokTok/c-toxcore/pull/70/files). Toxcore was +made compatible with C++, allowing us to use C++ compiler to catch some +type casing issues +[\[8\]](https://github.com/TokTok/c-toxcore/pull/143), +[\[9\]](https://github.com/TokTok/c-toxcore/pull/170). The existing test +suite was improved +[\[10\]](https://github.com/irungentoo/toxcore/compare/755f084e8720b349026c85afbad58954cb7ff1d4...TokTok:de966cdf90843819e2f7287e22ddcb5f95491b18). +Group chat API was rewritten to follow the guidelines of the current +API[\[11\]](https://github.com/TokTok/c-toxcore/pull/135). Generally a +lot of other code improvements happened. + +To allow easier transition of clients from irungentoo/toxcore to +TokTok/c-toxcore, [0.0.1 version of TokTok/c-toxcore was +released](https://github.com/TokTok/c-toxcore/releases/tag/v0.0.1), +which would make it possible for clients to support both Toxcores at the +same time. µTox nightly has already transitioned to using +TokTok/c-toxcore, which means that the next release of µTox will be +using TokTok/c-toxcore. Antidote, Antox and qTox also have plans on +switching to TokTok/c-toxcore. + +Support for UPnP and NAT-PMP is coming to Toxcore +[soon](https://github.com/TokTok/c-toxcore/pull/209). +[UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal) +and [NAT-PMP](https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol) +are port forwarding mechanisms, they allow programs to automatically +setup a port forwarding rules on users' routers without users having to +manually do this. This solves the issue of routers not allowing someone +you have not communicated with before to send you data, improving Tox's +networking performance, as the hole punching workaround would not be +needed to get around this anymore. + +That’s all that has happened during last couple months, until the next +update! diff --git a/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.de.md b/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.de.md new file mode 100644 index 0000000..b694c32 --- /dev/null +++ b/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.de.md @@ -0,0 +1,43 @@ +Title: First Stable Release of TokTok Toxcore +Date: 2016-12-20 05:04 +Author: oranges +Category: development +Status: published + +Good news everyone! + +The first stable version of TokTok Toxcore, 0.1.0, [got +released](https://github.com/TokTok/c-toxcore/releases/tag/v0.1.0). This +release will be API compatible with other 0.1.x releases, until 0.2.0 is +released, which will break the API. + +This marks the first stable release of TokTok Toxcore and is an exciting +milestone on the road to future Toxcore improvements. + +The packages of TokTok Toxcore are now available in the stable and +nightly streams on pkg.tox.chat. + +Most clients are switching to using TokTok Toxcore as their Toxcore +library. Antidote and µTox clients already use TokTok Toxcore, qTox has +gained support for TokTok Toxcore and will use it in the next release, +and Antox and Toxic are in the process of gaining support for TokTok +Toxcore. + +Thanks to [iphy, grayhatter, nurupo and +others](https://github.com/TokTok/c-toxcore/compare/v0.0.1...TokTok:v0.1.1) +for their hard work on Toxcore, as well as thanks to Encrypt for the +work on packaging it. + +TokTok Toxcore version follows the rules of [Semantic +Versioning](http://semver.org/). The API promise of x.y.z version is +defined to be the same as the Semantic Versioning API promise of x.y.z +with leading zeros stripped, meaning 0.1.0 has the same API promise as +1.0.0. + +While we were being excited with the 0.1.0 release, TokTok Toxcore has +already [released 0.1.1 +version](https://github.com/TokTok/c-toxcore/releases/tag/v0.1.1). The +current release cycle of patch versions is approximately one per week, +so they keep incrementing relatively fast. + +Happy Toxing! diff --git a/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.en.md b/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.en.md new file mode 100644 index 0000000..b694c32 --- /dev/null +++ b/content/blog/2016-12-20_first-stable-release-of-toktok-toxcore.en.md @@ -0,0 +1,43 @@ +Title: First Stable Release of TokTok Toxcore +Date: 2016-12-20 05:04 +Author: oranges +Category: development +Status: published + +Good news everyone! + +The first stable version of TokTok Toxcore, 0.1.0, [got +released](https://github.com/TokTok/c-toxcore/releases/tag/v0.1.0). This +release will be API compatible with other 0.1.x releases, until 0.2.0 is +released, which will break the API. + +This marks the first stable release of TokTok Toxcore and is an exciting +milestone on the road to future Toxcore improvements. + +The packages of TokTok Toxcore are now available in the stable and +nightly streams on pkg.tox.chat. + +Most clients are switching to using TokTok Toxcore as their Toxcore +library. Antidote and µTox clients already use TokTok Toxcore, qTox has +gained support for TokTok Toxcore and will use it in the next release, +and Antox and Toxic are in the process of gaining support for TokTok +Toxcore. + +Thanks to [iphy, grayhatter, nurupo and +others](https://github.com/TokTok/c-toxcore/compare/v0.0.1...TokTok:v0.1.1) +for their hard work on Toxcore, as well as thanks to Encrypt for the +work on packaging it. + +TokTok Toxcore version follows the rules of [Semantic +Versioning](http://semver.org/). The API promise of x.y.z version is +defined to be the same as the Semantic Versioning API promise of x.y.z +with leading zeros stripped, meaning 0.1.0 has the same API promise as +1.0.0. + +While we were being excited with the 0.1.0 release, TokTok Toxcore has +already [released 0.1.1 +version](https://github.com/TokTok/c-toxcore/releases/tag/v0.1.1). The +current release cycle of patch versions is approximately one per week, +so they keep incrementing relatively fast. + +Happy Toxing! diff --git a/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.de.md b/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.de.md new file mode 100644 index 0000000..c969a3d --- /dev/null +++ b/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.de.md @@ -0,0 +1,16 @@ +Title: Bug in musl-libc discovered, affecting the fully static Toxic builds +Date: 2017-10-20 19:49 +Author: nurupo +Category: Security Announcement +Status: published + +We advise everyone using the fully static Toxic builds that are listed +on our [download page](https://tox.chat/download.html) to update them to +the newest version by re-downloading them from that page. Those Toxic +builds use musl-libc and there was a fairly serious bug discovered in +musl-libc +([CVE-2017-15650](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15650)) +and [patched +yesterday](https://git.musl-libc.org/cgit/musl/commit/?id=45ca5d3fcb6f874bf5ba55d0e9651cef68515395) +. The new Toxic builds include this patch. This affects only the fully +static Toxic builds, no other builds currently use musl-libc. diff --git a/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.en.md b/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.en.md new file mode 100644 index 0000000..c969a3d --- /dev/null +++ b/content/blog/2017-10-20_bug-in-musl-libc-discovered-affecting-the-fully-static-toxic-builds.en.md @@ -0,0 +1,16 @@ +Title: Bug in musl-libc discovered, affecting the fully static Toxic builds +Date: 2017-10-20 19:49 +Author: nurupo +Category: Security Announcement +Status: published + +We advise everyone using the fully static Toxic builds that are listed +on our [download page](https://tox.chat/download.html) to update them to +the newest version by re-downloading them from that page. Those Toxic +builds use musl-libc and there was a fairly serious bug discovered in +musl-libc +([CVE-2017-15650](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15650)) +and [patched +yesterday](https://git.musl-libc.org/cgit/musl/commit/?id=45ca5d3fcb6f874bf5ba55d0e9651cef68515395) +. The new Toxic builds include this patch. This affects only the fully +static Toxic builds, no other builds currently use musl-libc. diff --git a/content/blog/2018-01-12_contributors-wanted.de.md b/content/blog/2018-01-12_contributors-wanted.de.md new file mode 100644 index 0000000..7a08be5 --- /dev/null +++ b/content/blog/2018-01-12_contributors-wanted.de.md @@ -0,0 +1,113 @@ +Title: Contributors wanted +Date: 2018-01-12 16:29 +Author: nurupo +Category: Uncategorized +Status: published + +It's common knowledge that any open source project wouldn't mind having +more contributors and Tox is not an exception. This blog post is for +those who want to contribute but don't know where to start. + +Starting contributing to Tox is as easy as joining [\#toktok channel on +Freenode IRC](https://wiki.tox.chat/users/community#irc), which is where +majority of the development discussion takes place, and asking what part +of Tox would benefit the most given your skill set and interests, unless +you already have an idea which part of Tox you would like to help with. +Just note that it might take some time for you to get a reply as not +everyone is always in the chat, so please be patient. Many Tox +developers and community members are connected to the chat 24/7 but get +on it only in their free time. Mailing list might sound more appropriate +for such possibly asynchronous discussions, and we do have a mailing +list, but it doesn't seem to catch on among developers much, so you will +get better response on IRC. + +Here is a non-exhaustive list of things you could help with, just to +give an idea. + +Non-programming +=============== + +You don't have to know programming in order to help. You can help by +testing nightly builds of clients and translating clients to different +languages. + +Testing clients +--------------- + +You can help by testing nightly builds of Tox clients, the +in-development, yet to be released, versions of clients, and reporting +any problems you encounter to the developers. Testing nightly builds can +help to find bugs and get them fixed before a release is made. Some +clients don't have nightly builds available for testing, or they do but +they are not well maintained and might be broken. If this is the case +for a client you want to test, simply asking developers for nightlies +should resolve this issue. Also, even if the client you test is +non-nightly, your testing is still useful. Just make sure that you are +testing the latest release version of the client, as any issues you +encounter might have been fixed in a newer version. You can get a client +to test from the [Download page](https://tox.chat/download.html) of our +website. You can provide feedback to the client developers by opening an +issue in the client's issue tracker, which is generally located on the +client's [repository page](https://tox.chat/clients.html). When +reporting feedback, especially bugs, is a good idea to provide as much +information to the developers as possible: operating system you are +running and the version of it, the version of the Tox client you are +running, exact steps on to how to reproduce the issue you are having and +what you have expected to happen instead when you took those steps. + +Translating clients +------------------- + +Some of the clients support multiple languages in their user interface, +you can help translate the user interface to any language you know and +correct existing translations if you find them unsatisfactory. + +Here are links for some of clients: + +- [Antidote](https://github.com/Antidote-for-Tox/Antidote/blob/d4018af502d7cb82d9f477e2078227b89a8d1d3a/FAQ/en.md#translations) +- [qTox](https://github.com/qTox/qTox/wiki/Translating) +- [uTox](https://github.com/uTox/uTox/tree/develop/langs) + +Programming-related +=================== + +Software development +-------------------- + +Anyone with programming background is welcome, as we have quite diverse +codebases. We could use help of people familiar with any of C, C++, Go, +Haskell, Java, Python, Rust, Scala, Swift and other. Familiarity with +networking, peer-to-peer software design, distributed hash table, +cryptography and writing secure code is preferred, but not required for +all of the codebases we have. You can help with an existing software +project or start a new project of your own that would be useful to Tox. +Also, you don't have to write code to contribute. Reviewing the code +that is considered for merging into the codebase is also a great way to +help. + +Website development +------------------- + +We are in need of a website developer/designer or anyone familiar with +HTML, CSS, Bootstrap, Jinja 2 templates and Python. The person currently +maintaining the website is more of a C++ developer than a web developer, +so while they keep the information on the website up-to-date, doing more +involved changes, like changing the page layout, is something that is +hard for them. The Tox website [doesn't use anything +fancy](https://github.com/Tox/tox.chat), we try to keep it as simple as +possible: it's a static page website which uses Jinja2 template engine +and Python for page generation. We limit the use of JavaScript to the +point that the website is perfectly functional without it while enabling +it adds optional enhancements. + +Packaging +--------- + +We are in need of package maintainers (to the point that we don't have +packages for Ubuntu 17.10 (Artful) at all), anyone familiar with shell +scripting, building software, debugging and fixing failed builds and +creating packages is welcome. We maintain Debian and Ubuntu package +repositories, with packages being created using pbuilder, so familiarity +with pbuilder helps. + +Join \#toktok and become a contributor today! diff --git a/content/blog/2018-01-12_contributors-wanted.en.md b/content/blog/2018-01-12_contributors-wanted.en.md new file mode 100644 index 0000000..7a08be5 --- /dev/null +++ b/content/blog/2018-01-12_contributors-wanted.en.md @@ -0,0 +1,113 @@ +Title: Contributors wanted +Date: 2018-01-12 16:29 +Author: nurupo +Category: Uncategorized +Status: published + +It's common knowledge that any open source project wouldn't mind having +more contributors and Tox is not an exception. This blog post is for +those who want to contribute but don't know where to start. + +Starting contributing to Tox is as easy as joining [\#toktok channel on +Freenode IRC](https://wiki.tox.chat/users/community#irc), which is where +majority of the development discussion takes place, and asking what part +of Tox would benefit the most given your skill set and interests, unless +you already have an idea which part of Tox you would like to help with. +Just note that it might take some time for you to get a reply as not +everyone is always in the chat, so please be patient. Many Tox +developers and community members are connected to the chat 24/7 but get +on it only in their free time. Mailing list might sound more appropriate +for such possibly asynchronous discussions, and we do have a mailing +list, but it doesn't seem to catch on among developers much, so you will +get better response on IRC. + +Here is a non-exhaustive list of things you could help with, just to +give an idea. + +Non-programming +=============== + +You don't have to know programming in order to help. You can help by +testing nightly builds of clients and translating clients to different +languages. + +Testing clients +--------------- + +You can help by testing nightly builds of Tox clients, the +in-development, yet to be released, versions of clients, and reporting +any problems you encounter to the developers. Testing nightly builds can +help to find bugs and get them fixed before a release is made. Some +clients don't have nightly builds available for testing, or they do but +they are not well maintained and might be broken. If this is the case +for a client you want to test, simply asking developers for nightlies +should resolve this issue. Also, even if the client you test is +non-nightly, your testing is still useful. Just make sure that you are +testing the latest release version of the client, as any issues you +encounter might have been fixed in a newer version. You can get a client +to test from the [Download page](https://tox.chat/download.html) of our +website. You can provide feedback to the client developers by opening an +issue in the client's issue tracker, which is generally located on the +client's [repository page](https://tox.chat/clients.html). When +reporting feedback, especially bugs, is a good idea to provide as much +information to the developers as possible: operating system you are +running and the version of it, the version of the Tox client you are +running, exact steps on to how to reproduce the issue you are having and +what you have expected to happen instead when you took those steps. + +Translating clients +------------------- + +Some of the clients support multiple languages in their user interface, +you can help translate the user interface to any language you know and +correct existing translations if you find them unsatisfactory. + +Here are links for some of clients: + +- [Antidote](https://github.com/Antidote-for-Tox/Antidote/blob/d4018af502d7cb82d9f477e2078227b89a8d1d3a/FAQ/en.md#translations) +- [qTox](https://github.com/qTox/qTox/wiki/Translating) +- [uTox](https://github.com/uTox/uTox/tree/develop/langs) + +Programming-related +=================== + +Software development +-------------------- + +Anyone with programming background is welcome, as we have quite diverse +codebases. We could use help of people familiar with any of C, C++, Go, +Haskell, Java, Python, Rust, Scala, Swift and other. Familiarity with +networking, peer-to-peer software design, distributed hash table, +cryptography and writing secure code is preferred, but not required for +all of the codebases we have. You can help with an existing software +project or start a new project of your own that would be useful to Tox. +Also, you don't have to write code to contribute. Reviewing the code +that is considered for merging into the codebase is also a great way to +help. + +Website development +------------------- + +We are in need of a website developer/designer or anyone familiar with +HTML, CSS, Bootstrap, Jinja 2 templates and Python. The person currently +maintaining the website is more of a C++ developer than a web developer, +so while they keep the information on the website up-to-date, doing more +involved changes, like changing the page layout, is something that is +hard for them. The Tox website [doesn't use anything +fancy](https://github.com/Tox/tox.chat), we try to keep it as simple as +possible: it's a static page website which uses Jinja2 template engine +and Python for page generation. We limit the use of JavaScript to the +point that the website is perfectly functional without it while enabling +it adds optional enhancements. + +Packaging +--------- + +We are in need of package maintainers (to the point that we don't have +packages for Ubuntu 17.10 (Artful) at all), anyone familiar with shell +scripting, building software, debugging and fixing failed builds and +creating packages is welcome. We maintain Debian and Ubuntu package +repositories, with packages being created using pbuilder, so familiarity +with pbuilder helps. + +Join \#toktok and become a contributor today! diff --git a/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.de.md b/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.de.md new file mode 100644 index 0000000..f5f3f81 --- /dev/null +++ b/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.de.md @@ -0,0 +1,62 @@ +Title: Update on Toxcore and the upcoming breaking version +Date: 2018-01-12 15:30 +Author: nurupo +Category: development +Status: published + +Hello everyone! Time flies fast, we spent all of 2017 without any status +update, so a blog post is due, especially given that we are about to hit +a new milestone and introduce some breaking changes. + +Since our last blog post about [Toxcore getting a stable version +release]({filename}2016-12-20_first-stable-release-of-toktok-toxcore.en.md), +version 0.1.0, Toxcore has seen eleven more releases, which brings it to +the version 0.1.11. Some of the notable changes in these releases +include: (a little) reduction of bandwidth usage +[\[1\]](https://github.com/TokTok/c-toxcore/pull/542), +[\[2\]](https://github.com/TokTok/c-toxcore/pull/511), fix of issues +related to reconnecting +[\[3\]](https://github.com/TokTok/c-toxcore/pull/615), improvement of +LAN discovery [\[4\]](https://github.com/TokTok/c-toxcore/pull/586), +ability to disable LAN discovery +[\[5\]](https://github.com/TokTok/c-toxcore/pull/306), fix of the read +receipts sometimes never arriving +[\[6\]](https://github.com/TokTok/c-toxcore/pull/500), reduced video +corruption [\[7\]](https://github.com/TokTok/c-toxcore/pull/623) and +better support of the FreeBSD platform +[\[8\]](https://github.com/TokTok/c-toxcore/pull/424), +[\[9\]](https://github.com/TokTok/c-toxcore/pull/473), +[\[10\]](https://github.com/TokTok/c-toxcore/pull/505), +[\[11\]](https://github.com/TokTok/c-toxcore/pull/635), +[\[12\]](https://github.com/TokTok/c-toxcore/pull/648) and the Microsoft +Visual C++ compiler +[\[13\]](https://github.com/TokTok/c-toxcore/pull/452), +[\[14\]](https://github.com/TokTok/c-toxcore/pull/479), +[\[15\]](https://github.com/TokTok/c-toxcore/pull/481), +[\[16\]](https://github.com/TokTok/c-toxcore/pull/556). Aside from +these, there were also many other bug fixes and code maintainability +improvements. + +The next Toxcore release that is planned after 0.1.11 is 0.2.0. Toxcore +versioning scheme follows that of Semantic Versioning with x.y.z +versions with leading zeros being stripped, meaning that 0.1.0 has the +same API promise as 1.0.0. Which means that 0.2.0 will be a breaking +release, it will break the compatibility with 0.1.x versions. Some of +the breaking changes planned for 0.2.0 include: removal of the toxdns +library [\[17\]](https://github.com/TokTok/c-toxcore/pull/650), building +resulting in just a single Toxcore library file containing all +sublibraries' code +[\[18\]](https://github.com/TokTok/c-toxcore/pull/442) and +toxencryptsave library's API breakage +[\[19\]](https://github.com/TokTok/c-toxcore/pull/334). Other breaking +changes might be added as the work on 0.2.0 release goes on. + +It's worth to note that since our last Toxcore blog post the adoption of +the [TokTok Toxcore](https://github.com/TokTok/c-toxcore/) fork of the +[original Toxcore](https://github.com/irungentoo/toxcore) has been going +well and all of the actively maintained clients have switched to using +it as their Toxcore library. + +That's all with updates on Toxcore. + +As usual, happy Toxing! diff --git a/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.en.md b/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.en.md new file mode 100644 index 0000000..f5f3f81 --- /dev/null +++ b/content/blog/2018-01-12_update-on-toxcore-and-the-upcoming-breaking-version.en.md @@ -0,0 +1,62 @@ +Title: Update on Toxcore and the upcoming breaking version +Date: 2018-01-12 15:30 +Author: nurupo +Category: development +Status: published + +Hello everyone! Time flies fast, we spent all of 2017 without any status +update, so a blog post is due, especially given that we are about to hit +a new milestone and introduce some breaking changes. + +Since our last blog post about [Toxcore getting a stable version +release]({filename}2016-12-20_first-stable-release-of-toktok-toxcore.en.md), +version 0.1.0, Toxcore has seen eleven more releases, which brings it to +the version 0.1.11. Some of the notable changes in these releases +include: (a little) reduction of bandwidth usage +[\[1\]](https://github.com/TokTok/c-toxcore/pull/542), +[\[2\]](https://github.com/TokTok/c-toxcore/pull/511), fix of issues +related to reconnecting +[\[3\]](https://github.com/TokTok/c-toxcore/pull/615), improvement of +LAN discovery [\[4\]](https://github.com/TokTok/c-toxcore/pull/586), +ability to disable LAN discovery +[\[5\]](https://github.com/TokTok/c-toxcore/pull/306), fix of the read +receipts sometimes never arriving +[\[6\]](https://github.com/TokTok/c-toxcore/pull/500), reduced video +corruption [\[7\]](https://github.com/TokTok/c-toxcore/pull/623) and +better support of the FreeBSD platform +[\[8\]](https://github.com/TokTok/c-toxcore/pull/424), +[\[9\]](https://github.com/TokTok/c-toxcore/pull/473), +[\[10\]](https://github.com/TokTok/c-toxcore/pull/505), +[\[11\]](https://github.com/TokTok/c-toxcore/pull/635), +[\[12\]](https://github.com/TokTok/c-toxcore/pull/648) and the Microsoft +Visual C++ compiler +[\[13\]](https://github.com/TokTok/c-toxcore/pull/452), +[\[14\]](https://github.com/TokTok/c-toxcore/pull/479), +[\[15\]](https://github.com/TokTok/c-toxcore/pull/481), +[\[16\]](https://github.com/TokTok/c-toxcore/pull/556). Aside from +these, there were also many other bug fixes and code maintainability +improvements. + +The next Toxcore release that is planned after 0.1.11 is 0.2.0. Toxcore +versioning scheme follows that of Semantic Versioning with x.y.z +versions with leading zeros being stripped, meaning that 0.1.0 has the +same API promise as 1.0.0. Which means that 0.2.0 will be a breaking +release, it will break the compatibility with 0.1.x versions. Some of +the breaking changes planned for 0.2.0 include: removal of the toxdns +library [\[17\]](https://github.com/TokTok/c-toxcore/pull/650), building +resulting in just a single Toxcore library file containing all +sublibraries' code +[\[18\]](https://github.com/TokTok/c-toxcore/pull/442) and +toxencryptsave library's API breakage +[\[19\]](https://github.com/TokTok/c-toxcore/pull/334). Other breaking +changes might be added as the work on 0.2.0 release goes on. + +It's worth to note that since our last Toxcore blog post the adoption of +the [TokTok Toxcore](https://github.com/TokTok/c-toxcore/) fork of the +[original Toxcore](https://github.com/irungentoo/toxcore) has been going +well and all of the actively maintained clients have switched to using +it as their Toxcore library. + +That's all with updates on Toxcore. + +As usual, happy Toxing! diff --git a/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.de.md b/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.de.md new file mode 100644 index 0000000..679f47b --- /dev/null +++ b/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.de.md @@ -0,0 +1,15 @@ +Title: Shutdown of the Debian and Ubuntu package repository +Date: 2018-02-23 10:45 +Author: nurupo +Category: Uncategorized +Status: published + +I'm sad to announce this, but we have to shut down the [Debian and +Ubuntu package repository](https://pkg.tox.chat/debian/) due to it being +unmaintained and thus having outdated or even possibly broken packages. +It has been several months since our last package maintainer maintained +any packages and our search for a new package maintainer didn't result +in anything. The package repository is planned to be shut down sometime +in the first half of March. The package repository might return in the +future if there would be enough people willing to maintain it, but for +now we have no choice but to close it. diff --git a/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.en.md b/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.en.md new file mode 100644 index 0000000..679f47b --- /dev/null +++ b/content/blog/2018-02-23_shutdown-of-the-debian-and-ubuntu-package-repository.en.md @@ -0,0 +1,15 @@ +Title: Shutdown of the Debian and Ubuntu package repository +Date: 2018-02-23 10:45 +Author: nurupo +Category: Uncategorized +Status: published + +I'm sad to announce this, but we have to shut down the [Debian and +Ubuntu package repository](https://pkg.tox.chat/debian/) due to it being +unmaintained and thus having outdated or even possibly broken packages. +It has been several months since our last package maintainer maintained +any packages and our search for a new package maintainer didn't result +in anything. The package repository is planned to be shut down sometime +in the first half of March. The package repository might return in the +future if there would be enough people willing to maintain it, but for +now we have no choice but to close it. diff --git a/content/blog/2018-03-02_toxcore-v0-2-0-released.de.md b/content/blog/2018-03-02_toxcore-v0-2-0-released.de.md new file mode 100644 index 0000000..b979f33 --- /dev/null +++ b/content/blog/2018-03-02_toxcore-v0-2-0-released.de.md @@ -0,0 +1,35 @@ +Title: Toxcore v0.2.0 released +Date: 2018-03-02 20:15 +Author: nurupo +Category: Uncategorized +Status: published + +We are happy to announce the release of Toxcore v0.2.0. Download the +tarballs, verify the signatures and read the changelog on [Toxcore's +GitHub Releases +page](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.0). + +Some of the notable changes in this release are: fix for large video +frame corruption [\[1\]](https://github.com/TokTok/c-toxcore/pull/718), +removal of libtoxdns +[\[2\]](https://github.com/TokTok/c-toxcore/pull/650), small API +breaking changes in tox.h, toxav.h and toxencryptsave.h +[\[3\]](https://github.com/TokTok/c-toxcore/pull/771), +[\[4\]](https://github.com/TokTok/c-toxcore/pull/799), +[\[5\]](https://github.com/TokTok/c-toxcore/pull/821), +[\[6\]](https://github.com/TokTok/c-toxcore/pull/578), +[\[7\]](https://github.com/TokTok/c-toxcore/pull/734), +[\[8\]](https://github.com/TokTok/c-toxcore/pull/334), API deprecation +notices for APIs that will get removed in v0.3.0 +[\[9\]](https://github.com/TokTok/c-toxcore/pull/798), and a build +script change that results in a single big libtoxcore library being +built, instead of separate libtoxcore, libtoxav and libtoxencryptsave +like it was before +[\[10\]](https://github.com/TokTok/c-toxcore/pull/442). One of the +changes that we hoped would get in v0.2.0 but it didn't was persistent +group chats, but with how things are going it's set to be added in one +of the v0.2.x releases. + +Some clients already have support for Toxcore v0.2.0, for example [Toxic +v0.8.2](https://github.com/JFreegman/toxic/releases/tag/v0.8.2) and qTox +master, while other clients are working on adding the support. diff --git a/content/blog/2018-03-02_toxcore-v0-2-0-released.en.md b/content/blog/2018-03-02_toxcore-v0-2-0-released.en.md new file mode 100644 index 0000000..b979f33 --- /dev/null +++ b/content/blog/2018-03-02_toxcore-v0-2-0-released.en.md @@ -0,0 +1,35 @@ +Title: Toxcore v0.2.0 released +Date: 2018-03-02 20:15 +Author: nurupo +Category: Uncategorized +Status: published + +We are happy to announce the release of Toxcore v0.2.0. Download the +tarballs, verify the signatures and read the changelog on [Toxcore's +GitHub Releases +page](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.0). + +Some of the notable changes in this release are: fix for large video +frame corruption [\[1\]](https://github.com/TokTok/c-toxcore/pull/718), +removal of libtoxdns +[\[2\]](https://github.com/TokTok/c-toxcore/pull/650), small API +breaking changes in tox.h, toxav.h and toxencryptsave.h +[\[3\]](https://github.com/TokTok/c-toxcore/pull/771), +[\[4\]](https://github.com/TokTok/c-toxcore/pull/799), +[\[5\]](https://github.com/TokTok/c-toxcore/pull/821), +[\[6\]](https://github.com/TokTok/c-toxcore/pull/578), +[\[7\]](https://github.com/TokTok/c-toxcore/pull/734), +[\[8\]](https://github.com/TokTok/c-toxcore/pull/334), API deprecation +notices for APIs that will get removed in v0.3.0 +[\[9\]](https://github.com/TokTok/c-toxcore/pull/798), and a build +script change that results in a single big libtoxcore library being +built, instead of separate libtoxcore, libtoxav and libtoxencryptsave +like it was before +[\[10\]](https://github.com/TokTok/c-toxcore/pull/442). One of the +changes that we hoped would get in v0.2.0 but it didn't was persistent +group chats, but with how things are going it's set to be added in one +of the v0.2.x releases. + +Some clients already have support for Toxcore v0.2.0, for example [Toxic +v0.8.2](https://github.com/JFreegman/toxic/releases/tag/v0.8.2) and qTox +master, while other clients are working on adding the support. diff --git a/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.de.md b/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.de.md new file mode 100644 index 0000000..ae5d43a --- /dev/null +++ b/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.de.md @@ -0,0 +1,123 @@ +Title: Security vulnerability and new Toxcore release +Date: 2018-04-20 00:20 +Author: nurupo +Category: Security Announcement +Status: published + +A vulnerability was discovered in Toxcore that allows one to learn the +IP of a target user by only knowing their Tox Id and without being +friends with the target user. + +The Tox protocol is designed in such a way that only friends (contacts) +which you have accepted friend requests of are able to learn your IP +based on your Tox Id and no one else. Thus, being able to learn the IP +of an owner of a Tox Id without them accepting a friend request is an +undesired behavior. + +This is a vulnerability in an implementation of the Tox protocol, a +vulnerability in the Toxcore library, not in the Tox protocol itself. + +The vulnerability affects both [TokTok's +c-toxcore](https://github.com/TokTok/c-toxcore/) and [irungentoo's +toxcore](https://github.com/irungentoo/toxcore). The vulnerability +affects only UDP mode of operation. TCP-only mode is not affected by the +vulnerability. + +TokTok's c-toxcore has patched the vulnerability in [version +0.2.2](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.2). +~~irungentoo's toxcore doesn't have the vulnerability patched as of this +moment and it's unknown if it ever will, as it hasn't been actively +maintained for years.~~ irungentoo's toxcore was patched after this post +was written. + +The vulnerability was privately reported to us by [Evgeny +Kurnevsky](https://github.com/kurnevsky) on April 14th and [publicly +disclosed](https://github.com/TokTok/c-toxcore/issues/873) with our +permission on April 15th, along with [a +patch](https://github.com/TokTok/c-toxcore/pull/872) fixing the +vulnerability, made by Evgeny Kurnevsky. The vulnerability was found +when Evgeny was working on [tox-rs](https://github.com/tox-rs/tox) +project - a Tox implementation in Rust. + +We urge everyone to update to the latest TokTok c-toxcore as soon as +possible. You can immediately mitigate the vulnerability for yourself by +using TCP-only mode. + +Due to the nature of the vulnerability, using Toxcore in which the +vulnerability is patched is not enough to protect yourself. The way the +patch works is that it can't protect you from the vulnerability but it +can and does protect other peers. So in order to be protected from the +vulnerability, everyone should switch to using the patched Toxcore. The +more people use the patched Toxcore, the less is the chance to be +vulnerable. Note that this applies only to the UDP mode. If you use the +TCP-only mode, you are fully protected as you are not affected by the +vulnerability. + +Details of the vulnerability +---------------------------- + +Here are the technical details of the vulnerability. + +The vulnerability is caused by the Onion module of Toxcore erroneously +allowing to onion-route any data, any Tox packets, without a +restriction. By the Tox protocol specification, when Alice makes an +onion-routed request to Bob and then Bob sends an onion-routed response +back to Alice, the payload of the onion-routed response sent by Bob +arrives to Alice as it is, stripped of any identification that it was +ever onion-routed by the last onion hop, and is interpreted as a regular +Tox packet by Alice. Alice has no way to distinguish onion and non-onion +packets -- she has no idea if the packet originated from the node it +received the packet from, or if the packet was relayed on someone else's +behalf as part of an onion-routing. The way the onion routing is defined +in the Tox specification and Toxcore erroneously not restricting the +packets that can be onion-routed allows for some interesting +interactions that weren't meant to happen. + +One of the packets that are onion-routed is the Announce Request packet. +It's used to announce ourselves to nodes close to our long term public +key, the one that is a part of Tox Id, and the payload of that packet +includes the long term public key itself. Let's say Alice announces +herself to a bunch of nodes, one of which happened to be Bob. (If Bob is +malicious, he can purposefully keep re-generating his DHT keypair until +his public key becomes close to Alice's long term public key as to +guarantee Alice announcing to him.) Based on the Announce Request +packet, Bob now knows Alice's long term public key and has a way to +contact her back though the established onion path. If Bob is malicious, +he could spawn many new DHT nodes, and send back to Alice a NAT Ping +Request packet for one of its newly created nodes. The NAT Ping Request +packet is used to ping a node on someone else's behalf in order to +circumvent the NAT. The NAT Ping Request is not meant to be onion +routed. Alice will receive the NAT Ping Request packet and will +diligently relay it to the Bob's DHT node if it happened to be in +Alice's Close List of nodes, which will happen only if the DHT public +key of Bob's node is close to the DHT public key of Alice's node. Bob +doesn't know Alice's DHT public key, so Bob will have to make a guess. +If Bob makes a bad guess and Alice doesn't relay the packet to his node, +Bob can re-try by sending the NAT Ping Request packet to Alice for a new +DHT node, repeating this process as many times as he wants. Eventually +Bob's DHT node will have public key close to Alice's DHT public key and +end up in Alice's Close Nodes list, making Alice relay the NAT Ping +Request packet to it, unknowingly disclosing her IP to Bob. Now Bob +knows both Alice's long term public key and her IP without being friends +with her. + +What the patch does is make all nodes in the onion path check if the +payload of the onion-routed response is a packet kind that shouldn't be +routed through the onion, and if so drop it. It also makes the node +closest to the destination of the onion-routed request, which is the +only node in the onion path of the onion-routed request that can see +which packet kind is sent to the destination node, drop the onion-routed +request if it has a packet kind that shouldn't be routed through the +onion. The latter doesn't matter much as Alice can't exploit Bob in any +way by onion-routing him packets that are not supposed to be onion +routed, it's done more for data sanitization reasons. + +Because there are only 3 nodes in the onion path, the source and +destination excluded, the patch protects you as long as at least one of +the three is using the patched Toxcore. + +This vulnerability affects only the UDP mode. In TCP-only mode the Onion +module restricts which Tox packets are onion-routed correctly, and the +Tox protocol specification is written in such a way that nodes using +TCP-only mode can distinguish between onion and non-onion packets. So +all of the above applies only to the UDP mode. diff --git a/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.en.md b/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.en.md new file mode 100644 index 0000000..ae5d43a --- /dev/null +++ b/content/blog/2018-04-20_security-vulnerability-and-new-toxcore-release.en.md @@ -0,0 +1,123 @@ +Title: Security vulnerability and new Toxcore release +Date: 2018-04-20 00:20 +Author: nurupo +Category: Security Announcement +Status: published + +A vulnerability was discovered in Toxcore that allows one to learn the +IP of a target user by only knowing their Tox Id and without being +friends with the target user. + +The Tox protocol is designed in such a way that only friends (contacts) +which you have accepted friend requests of are able to learn your IP +based on your Tox Id and no one else. Thus, being able to learn the IP +of an owner of a Tox Id without them accepting a friend request is an +undesired behavior. + +This is a vulnerability in an implementation of the Tox protocol, a +vulnerability in the Toxcore library, not in the Tox protocol itself. + +The vulnerability affects both [TokTok's +c-toxcore](https://github.com/TokTok/c-toxcore/) and [irungentoo's +toxcore](https://github.com/irungentoo/toxcore). The vulnerability +affects only UDP mode of operation. TCP-only mode is not affected by the +vulnerability. + +TokTok's c-toxcore has patched the vulnerability in [version +0.2.2](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.2). +~~irungentoo's toxcore doesn't have the vulnerability patched as of this +moment and it's unknown if it ever will, as it hasn't been actively +maintained for years.~~ irungentoo's toxcore was patched after this post +was written. + +The vulnerability was privately reported to us by [Evgeny +Kurnevsky](https://github.com/kurnevsky) on April 14th and [publicly +disclosed](https://github.com/TokTok/c-toxcore/issues/873) with our +permission on April 15th, along with [a +patch](https://github.com/TokTok/c-toxcore/pull/872) fixing the +vulnerability, made by Evgeny Kurnevsky. The vulnerability was found +when Evgeny was working on [tox-rs](https://github.com/tox-rs/tox) +project - a Tox implementation in Rust. + +We urge everyone to update to the latest TokTok c-toxcore as soon as +possible. You can immediately mitigate the vulnerability for yourself by +using TCP-only mode. + +Due to the nature of the vulnerability, using Toxcore in which the +vulnerability is patched is not enough to protect yourself. The way the +patch works is that it can't protect you from the vulnerability but it +can and does protect other peers. So in order to be protected from the +vulnerability, everyone should switch to using the patched Toxcore. The +more people use the patched Toxcore, the less is the chance to be +vulnerable. Note that this applies only to the UDP mode. If you use the +TCP-only mode, you are fully protected as you are not affected by the +vulnerability. + +Details of the vulnerability +---------------------------- + +Here are the technical details of the vulnerability. + +The vulnerability is caused by the Onion module of Toxcore erroneously +allowing to onion-route any data, any Tox packets, without a +restriction. By the Tox protocol specification, when Alice makes an +onion-routed request to Bob and then Bob sends an onion-routed response +back to Alice, the payload of the onion-routed response sent by Bob +arrives to Alice as it is, stripped of any identification that it was +ever onion-routed by the last onion hop, and is interpreted as a regular +Tox packet by Alice. Alice has no way to distinguish onion and non-onion +packets -- she has no idea if the packet originated from the node it +received the packet from, or if the packet was relayed on someone else's +behalf as part of an onion-routing. The way the onion routing is defined +in the Tox specification and Toxcore erroneously not restricting the +packets that can be onion-routed allows for some interesting +interactions that weren't meant to happen. + +One of the packets that are onion-routed is the Announce Request packet. +It's used to announce ourselves to nodes close to our long term public +key, the one that is a part of Tox Id, and the payload of that packet +includes the long term public key itself. Let's say Alice announces +herself to a bunch of nodes, one of which happened to be Bob. (If Bob is +malicious, he can purposefully keep re-generating his DHT keypair until +his public key becomes close to Alice's long term public key as to +guarantee Alice announcing to him.) Based on the Announce Request +packet, Bob now knows Alice's long term public key and has a way to +contact her back though the established onion path. If Bob is malicious, +he could spawn many new DHT nodes, and send back to Alice a NAT Ping +Request packet for one of its newly created nodes. The NAT Ping Request +packet is used to ping a node on someone else's behalf in order to +circumvent the NAT. The NAT Ping Request is not meant to be onion +routed. Alice will receive the NAT Ping Request packet and will +diligently relay it to the Bob's DHT node if it happened to be in +Alice's Close List of nodes, which will happen only if the DHT public +key of Bob's node is close to the DHT public key of Alice's node. Bob +doesn't know Alice's DHT public key, so Bob will have to make a guess. +If Bob makes a bad guess and Alice doesn't relay the packet to his node, +Bob can re-try by sending the NAT Ping Request packet to Alice for a new +DHT node, repeating this process as many times as he wants. Eventually +Bob's DHT node will have public key close to Alice's DHT public key and +end up in Alice's Close Nodes list, making Alice relay the NAT Ping +Request packet to it, unknowingly disclosing her IP to Bob. Now Bob +knows both Alice's long term public key and her IP without being friends +with her. + +What the patch does is make all nodes in the onion path check if the +payload of the onion-routed response is a packet kind that shouldn't be +routed through the onion, and if so drop it. It also makes the node +closest to the destination of the onion-routed request, which is the +only node in the onion path of the onion-routed request that can see +which packet kind is sent to the destination node, drop the onion-routed +request if it has a packet kind that shouldn't be routed through the +onion. The latter doesn't matter much as Alice can't exploit Bob in any +way by onion-routing him packets that are not supposed to be onion +routed, it's done more for data sanitization reasons. + +Because there are only 3 nodes in the onion path, the source and +destination excluded, the patch protects you as long as at least one of +the three is using the patched Toxcore. + +This vulnerability affects only the UDP mode. In TCP-only mode the Onion +module restricts which Tox packets are onion-routed correctly, and the +Tox protocol specification is written in such a way that nodes using +TCP-only mode can distinguish between onion and non-onion packets. So +all of the above applies only to the UDP mode. diff --git a/content/blog/2018-06-06_toxcon-2018.de.md b/content/blog/2018-06-06_toxcon-2018.de.md new file mode 100644 index 0000000..6b4291e --- /dev/null +++ b/content/blog/2018-06-06_toxcon-2018.de.md @@ -0,0 +1,18 @@ +Title: ToxCon 2018 +Date: 2018-06-06 13:29 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2018 Poster]({filename}static/images/toxcon-2018-poster.png) + +In October the Tox developer community will be holding a conference in +Vienna. Join us as we talk about the progress we have made during the +last 12 months with Tox and other security related topics. There will be +lots of talks and other cool things to see. + +For more details join the +[\#toxcon2018](https://webchat.freenode.net/?channels=#toxcon2018) IRC +channel on Freenode and contact *robinli*, *sudden6* or *zoff99*. + +More information will be revealed in a future post. diff --git a/content/blog/2018-06-06_toxcon-2018.en.md b/content/blog/2018-06-06_toxcon-2018.en.md new file mode 100644 index 0000000..6b4291e --- /dev/null +++ b/content/blog/2018-06-06_toxcon-2018.en.md @@ -0,0 +1,18 @@ +Title: ToxCon 2018 +Date: 2018-06-06 13:29 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2018 Poster]({filename}static/images/toxcon-2018-poster.png) + +In October the Tox developer community will be holding a conference in +Vienna. Join us as we talk about the progress we have made during the +last 12 months with Tox and other security related topics. There will be +lots of talks and other cool things to see. + +For more details join the +[\#toxcon2018](https://webchat.freenode.net/?channels=#toxcon2018) IRC +channel on Freenode and contact *robinli*, *sudden6* or *zoff99*. + +More information will be revealed in a future post. diff --git a/content/blog/2018-08-26_toxcon-2018-update.de.md b/content/blog/2018-08-26_toxcon-2018-update.de.md new file mode 100644 index 0000000..740066f --- /dev/null +++ b/content/blog/2018-08-26_toxcon-2018-update.de.md @@ -0,0 +1,33 @@ +Title: ToxCon 2018 Update +Date: 2018-08-26 04:06 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2018 Summary]({filename}static/images/toxcon-2018-summary.png) + +As promised, here is more information on ToxCon 2018. + +Tox developer community will be holding the conference from Friday, +October 12th, to Sunday, October 14th -- a 3 day event, at [Metalab +Vienna](https://twitter.com/metalabvie), a hackerspace [located in the +heart of Vienna, Austria](https://pretix.eu/ZMetalab/ToxCon2018/). We +have many talks prepared for you: from the progress Tox has made in the +last 12 months, to security-related and other interesting topics. The +the full schedule of the event [is available +online](https://tox.fahrplan.zoff.cc/booklet.html) and there is also an +[Android app](https://f-droid.org/packages/com.zoffcc.fahrplan.toxcon/) +that you can use to get updates if more talks get added. + +If you would like to learn more about Tox, meet the developers, do some +live hacking, or just socialize, then this is the event for you. [The +tickets are free](https://pretix.eu/ZMetalab/ToxCon2018/) and you have +an option to buy a sponsored ticket or a ToxCon T-shirt. All money from +the sponsored tickets and the T-shirt sales will go towards a dinner for +the speakers, and, if there is money left, T-shirts to give away. + +For questions about booking, travel arrangements, talks, or anything +related to the event feel free to join the +[\#toxcon2018](https://webchat.freenode.net/?channels=#toxcon2018) IRC +channel on Freenode and contact one of the event organizers: *robinli*, +*sudden6* or *zoff99*. diff --git a/content/blog/2018-08-26_toxcon-2018-update.en.md b/content/blog/2018-08-26_toxcon-2018-update.en.md new file mode 100644 index 0000000..740066f --- /dev/null +++ b/content/blog/2018-08-26_toxcon-2018-update.en.md @@ -0,0 +1,33 @@ +Title: ToxCon 2018 Update +Date: 2018-08-26 04:06 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2018 Summary]({filename}static/images/toxcon-2018-summary.png) + +As promised, here is more information on ToxCon 2018. + +Tox developer community will be holding the conference from Friday, +October 12th, to Sunday, October 14th -- a 3 day event, at [Metalab +Vienna](https://twitter.com/metalabvie), a hackerspace [located in the +heart of Vienna, Austria](https://pretix.eu/ZMetalab/ToxCon2018/). We +have many talks prepared for you: from the progress Tox has made in the +last 12 months, to security-related and other interesting topics. The +the full schedule of the event [is available +online](https://tox.fahrplan.zoff.cc/booklet.html) and there is also an +[Android app](https://f-droid.org/packages/com.zoffcc.fahrplan.toxcon/) +that you can use to get updates if more talks get added. + +If you would like to learn more about Tox, meet the developers, do some +live hacking, or just socialize, then this is the event for you. [The +tickets are free](https://pretix.eu/ZMetalab/ToxCon2018/) and you have +an option to buy a sponsored ticket or a ToxCon T-shirt. All money from +the sponsored tickets and the T-shirt sales will go towards a dinner for +the speakers, and, if there is money left, T-shirts to give away. + +For questions about booking, travel arrangements, talks, or anything +related to the event feel free to join the +[\#toxcon2018](https://webchat.freenode.net/?channels=#toxcon2018) IRC +channel on Freenode and contact one of the event organizers: *robinli*, +*sudden6* or *zoff99*. diff --git a/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.de.md b/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.de.md new file mode 100644 index 0000000..f2ab373 --- /dev/null +++ b/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.de.md @@ -0,0 +1,52 @@ +Title: Memory leak bug and new Toxcore release fixing it +Date: 2018-10-08 16:37 +Author: nurupo +Category: Security Announcement +Status: published + +A memory leak bug was discovered in Toxcore that can be triggered +remotely to exhaust one's system memory, resulting in a denial of +service attack. The bug is present in the TCP Server module of Toxcore +and therefore it affects mostly bootstrap nodes. Regular Tox clients +generally have the TCP Server functionality disabled by default, leaving +them unaffected. + +The bug was introduced on July 15th, 2014 in commit +[22d28ddf36563e2d0018fc20cafdfe61278dd67f](https://github.com/TokTok/c-toxcore/commit/22d28ddf36563e2d0018fc20cafdfe61278dd67f), +making all previous versions of [TokTok +c-toxcore](https://github.com/TokTok/c-toxcore/) and [irungentoo's +toxcore](https://github.com/irungentoo/toxcore) vulnerable. + +The bug is fixed in TokTok c-toxcore +[v0.2.8](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.8). The +bug is also fixed in the master branch of irungentoo's toxcore, in +commit +[bf69b54f64003d160d759068f4816b2d9b2e1e21](https://github.com/irungentoo/toxcore/commit/bf69b54f64003d160d759068f4816b2d9b2e1e21). +As a general reminder, if you are still using irungentoo's toxcore, we +strongly encourage you to switch to using TokTok c-toxcore instead as +it's a lot more actively developed and maintained. In fact, irungentoo's +toxcore is neither being developed nor maintained for some time now, +aside from merging only the most critical fixes from TokTok c-toxcore +from time to time, missing all other important fixes. + +If you are using TokTok c-toxcore v0.2.8, you should be unaffected by +this bug. + +If you are using an older Toxcore, for example a client you use didn't +release an update, make sure that you have the TCP Server functionality +disabled in the client settings and you should be unaffected. Some +clients, like qTox v1.16.3 and uTox v0.16.1, don't provide the user with +an option to enable the TCP Server, having it always disabled, and other +clients, like Toxic v0.8.2, do provide the TCP Server option, but it's +disabled by default. Note that it's possible that some other clients +have the TCP Server option enabled by default. + +If you are running a bootstrap node, we strongly encourage you to update +to TokTok c-toxcore v0.2.8 rather than disable the TCP Server option. In +fact, we will be making Toxcore v0.2.8 the minimal required version for +all of the nodes on our bootstrap node list. TCP relay functionality is +very useful for mobile users and those behind restrictive NATs, and +given that it's mostly bootstrap nodes that act as TCP relay servers, as +clients generally have that option disabled, even a few of those nodes +disabling TCP Server functionality would reduce the number of TCP relay +servers Tox clients can use considerably. diff --git a/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.en.md b/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.en.md new file mode 100644 index 0000000..f2ab373 --- /dev/null +++ b/content/blog/2018-10-08_memory-leak-bug-and-new-toxcore-release-fixing-it.en.md @@ -0,0 +1,52 @@ +Title: Memory leak bug and new Toxcore release fixing it +Date: 2018-10-08 16:37 +Author: nurupo +Category: Security Announcement +Status: published + +A memory leak bug was discovered in Toxcore that can be triggered +remotely to exhaust one's system memory, resulting in a denial of +service attack. The bug is present in the TCP Server module of Toxcore +and therefore it affects mostly bootstrap nodes. Regular Tox clients +generally have the TCP Server functionality disabled by default, leaving +them unaffected. + +The bug was introduced on July 15th, 2014 in commit +[22d28ddf36563e2d0018fc20cafdfe61278dd67f](https://github.com/TokTok/c-toxcore/commit/22d28ddf36563e2d0018fc20cafdfe61278dd67f), +making all previous versions of [TokTok +c-toxcore](https://github.com/TokTok/c-toxcore/) and [irungentoo's +toxcore](https://github.com/irungentoo/toxcore) vulnerable. + +The bug is fixed in TokTok c-toxcore +[v0.2.8](https://github.com/TokTok/c-toxcore/releases/tag/v0.2.8). The +bug is also fixed in the master branch of irungentoo's toxcore, in +commit +[bf69b54f64003d160d759068f4816b2d9b2e1e21](https://github.com/irungentoo/toxcore/commit/bf69b54f64003d160d759068f4816b2d9b2e1e21). +As a general reminder, if you are still using irungentoo's toxcore, we +strongly encourage you to switch to using TokTok c-toxcore instead as +it's a lot more actively developed and maintained. In fact, irungentoo's +toxcore is neither being developed nor maintained for some time now, +aside from merging only the most critical fixes from TokTok c-toxcore +from time to time, missing all other important fixes. + +If you are using TokTok c-toxcore v0.2.8, you should be unaffected by +this bug. + +If you are using an older Toxcore, for example a client you use didn't +release an update, make sure that you have the TCP Server functionality +disabled in the client settings and you should be unaffected. Some +clients, like qTox v1.16.3 and uTox v0.16.1, don't provide the user with +an option to enable the TCP Server, having it always disabled, and other +clients, like Toxic v0.8.2, do provide the TCP Server option, but it's +disabled by default. Note that it's possible that some other clients +have the TCP Server option enabled by default. + +If you are running a bootstrap node, we strongly encourage you to update +to TokTok c-toxcore v0.2.8 rather than disable the TCP Server option. In +fact, we will be making Toxcore v0.2.8 the minimal required version for +all of the nodes on our bootstrap node list. TCP relay functionality is +very useful for mobile users and those behind restrictive NATs, and +given that it's mostly bootstrap nodes that act as TCP relay servers, as +clients generally have that option disabled, even a few of those nodes +disabling TCP Server functionality would reduce the number of TCP relay +servers Tox clients can use considerably. diff --git a/content/blog/2018-11-12_toxcon-2018-report.de.md b/content/blog/2018-11-12_toxcon-2018-report.de.md new file mode 100644 index 0000000..8fcbd46 --- /dev/null +++ b/content/blog/2018-11-12_toxcon-2018-report.de.md @@ -0,0 +1,26 @@ +Title: ToxCon 2018 report +Date: 2018-11-12 22:37 +Author: nurupo +Category: Uncategorized +Status: published + +This year's ToxCon was super fun, thanks to everyone who attended it! + +If you have missed the event, [list of +talks](https://tox.fahrplan.zoff.cc/booklet.html), [talk slides and some +photos](https://github.com/Tox/events/tree/master/toxcon2018) from the +event are available online. No videos are available as it was decided +not to record the talks. + +We are planning to hold another ToxCon the next year, so keep an eye for +announcements. If you are working on anything fun with Tox and want to +share it with the world, consider giving a talk at the next ToxCon -- we +would be happy to host your talk. + +Here are a couple of the photos from the event. + +![ToxCon2018 organizers]({filename}static/images/toxcon-2018-organizers.jpg) +ToxCon2018 organizers + +![ToxCon2018 group photo]({filename}static/images/toxcon-2018-group.jpg) +ToxCon2018 group photo diff --git a/content/blog/2018-11-12_toxcon-2018-report.en.md b/content/blog/2018-11-12_toxcon-2018-report.en.md new file mode 100644 index 0000000..8fcbd46 --- /dev/null +++ b/content/blog/2018-11-12_toxcon-2018-report.en.md @@ -0,0 +1,26 @@ +Title: ToxCon 2018 report +Date: 2018-11-12 22:37 +Author: nurupo +Category: Uncategorized +Status: published + +This year's ToxCon was super fun, thanks to everyone who attended it! + +If you have missed the event, [list of +talks](https://tox.fahrplan.zoff.cc/booklet.html), [talk slides and some +photos](https://github.com/Tox/events/tree/master/toxcon2018) from the +event are available online. No videos are available as it was decided +not to record the talks. + +We are planning to hold another ToxCon the next year, so keep an eye for +announcements. If you are working on anything fun with Tox and want to +share it with the world, consider giving a talk at the next ToxCon -- we +would be happy to host your talk. + +Here are a couple of the photos from the event. + +![ToxCon2018 organizers]({filename}static/images/toxcon-2018-organizers.jpg) +ToxCon2018 organizers + +![ToxCon2018 group photo]({filename}static/images/toxcon-2018-group.jpg) +ToxCon2018 group photo diff --git a/content/blog/2019-05-21_toxcon-2019.de.md b/content/blog/2019-05-21_toxcon-2019.de.md new file mode 100644 index 0000000..7290b73 --- /dev/null +++ b/content/blog/2019-05-21_toxcon-2019.de.md @@ -0,0 +1,26 @@ +Title: ToxCon 2019 +Date: 2019-05-21 00:13 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2019 Poster]({filename}static/images/toxcon-2019-poster.png) + +This October the Tox developer community will be holding its third +annual conference at [Metalab](https://twitter.com/metalabvie) in the +heart of Vienna, Austria. The event will be 3 full days, from Friday, +October 11th to Sunday, October 13th. + +We will talk about Tox, and other security related and interesting +topics. If you would like to attend, meet the Tox devs, do some live +hacking, or just socialize -- [get a free ticket and reserve a +T-shirt](https://pretix.eu/ZMetalab/ToxCon2019/). You can find the exact +address on your ticket. + +Want to give a talk about your project? Please [apply +here](https://pretalx.tox.zoff.cc/toxcon2019/cfp)! + +If you have any questions about booking, travel arrangements, talks, or +anything related to the event, join +[\#toxcon](https://webchat.freenode.net/?channels=#toxcon) IRC channel +on Freenode and contact *robinli*, *strfry* or *zoff99*. diff --git a/content/blog/2019-05-21_toxcon-2019.en.md b/content/blog/2019-05-21_toxcon-2019.en.md new file mode 100644 index 0000000..7290b73 --- /dev/null +++ b/content/blog/2019-05-21_toxcon-2019.en.md @@ -0,0 +1,26 @@ +Title: ToxCon 2019 +Date: 2019-05-21 00:13 +Author: nurupo +Category: Uncategorized +Status: published + +![ToxCon 2019 Poster]({filename}static/images/toxcon-2019-poster.png) + +This October the Tox developer community will be holding its third +annual conference at [Metalab](https://twitter.com/metalabvie) in the +heart of Vienna, Austria. The event will be 3 full days, from Friday, +October 11th to Sunday, October 13th. + +We will talk about Tox, and other security related and interesting +topics. If you would like to attend, meet the Tox devs, do some live +hacking, or just socialize -- [get a free ticket and reserve a +T-shirt](https://pretix.eu/ZMetalab/ToxCon2019/). You can find the exact +address on your ticket. + +Want to give a talk about your project? Please [apply +here](https://pretalx.tox.zoff.cc/toxcon2019/cfp)! + +If you have any questions about booking, travel arrangements, talks, or +anything related to the event, join +[\#toxcon](https://webchat.freenode.net/?channels=#toxcon) IRC channel +on Freenode and contact *robinli*, *strfry* or *zoff99*. diff --git a/content/blog/static/images/irungentoo-indiegogo.png b/content/blog/static/images/irungentoo-indiegogo.png new file mode 100644 index 0000000..61daa31 Binary files /dev/null and b/content/blog/static/images/irungentoo-indiegogo.png differ diff --git a/content/blog/static/images/scale-14x-1.jpg b/content/blog/static/images/scale-14x-1.jpg new file mode 100644 index 0000000..7e452f9 Binary files /dev/null and b/content/blog/static/images/scale-14x-1.jpg differ diff --git a/content/blog/static/images/scale-14x-2.jpg b/content/blog/static/images/scale-14x-2.jpg new file mode 100644 index 0000000..0322054 Binary files /dev/null and b/content/blog/static/images/scale-14x-2.jpg differ diff --git a/content/blog/static/images/scale-14x-3.jpg b/content/blog/static/images/scale-14x-3.jpg new file mode 100644 index 0000000..6220f08 Binary files /dev/null and b/content/blog/static/images/scale-14x-3.jpg differ diff --git a/content/blog/static/images/scale-14x-4.jpg b/content/blog/static/images/scale-14x-4.jpg new file mode 100644 index 0000000..2a0ca22 Binary files /dev/null and b/content/blog/static/images/scale-14x-4.jpg differ diff --git a/content/blog/static/images/scale-14x-5.jpg b/content/blog/static/images/scale-14x-5.jpg new file mode 100644 index 0000000..e14cff9 Binary files /dev/null and b/content/blog/static/images/scale-14x-5.jpg differ diff --git a/content/blog/static/images/scale-14x-6.jpg b/content/blog/static/images/scale-14x-6.jpg new file mode 100644 index 0000000..5c6599e Binary files /dev/null and b/content/blog/static/images/scale-14x-6.jpg differ diff --git a/content/blog/static/images/scale-14x-7.jpg b/content/blog/static/images/scale-14x-7.jpg new file mode 100644 index 0000000..26a6803 Binary files /dev/null and b/content/blog/static/images/scale-14x-7.jpg differ diff --git a/content/blog/static/images/toxcon-2018-group.jpg b/content/blog/static/images/toxcon-2018-group.jpg new file mode 100644 index 0000000..9851c28 Binary files /dev/null and b/content/blog/static/images/toxcon-2018-group.jpg differ diff --git a/content/blog/static/images/toxcon-2018-organizers.jpg b/content/blog/static/images/toxcon-2018-organizers.jpg new file mode 100644 index 0000000..e962628 Binary files /dev/null and b/content/blog/static/images/toxcon-2018-organizers.jpg differ diff --git a/content/blog/static/images/toxcon-2018-poster.png b/content/blog/static/images/toxcon-2018-poster.png new file mode 100644 index 0000000..6785bbc Binary files /dev/null and b/content/blog/static/images/toxcon-2018-poster.png differ diff --git a/content/blog/static/images/toxcon-2018-summary.png b/content/blog/static/images/toxcon-2018-summary.png new file mode 100644 index 0000000..0bd3c2e Binary files /dev/null and b/content/blog/static/images/toxcon-2018-summary.png differ diff --git a/content/blog/static/images/toxcon-2019-poster.png b/content/blog/static/images/toxcon-2019-poster.png new file mode 100644 index 0000000..29be307 Binary files /dev/null and b/content/blog/static/images/toxcon-2019-poster.png differ diff --git a/content/website/about2.en.md b/content/website/about2.en.md new file mode 100644 index 0000000..0d07877 --- /dev/null +++ b/content/website/about2.en.md @@ -0,0 +1,49 @@ +Title: About + +# The Tox Project + +Tox began a few years ago, in the wake of Edward Snowden's leaks regarding NSA +spying activity. The idea was to create an instant messaging application that +ran without requiring the use of central servers. The system would be +distributed, peer-to-peer, and end-to-end encrypted, with no way to disable any +of the encryption features; at the same time, the application would be easily +usable by the layperson with no practical knowledge of cryptography or +distributed systems. During the Summer of 2013 a small group of developers from +all around the globe formed and began working on a library implementing the Tox +protocol. The library provides all of the messaging and encryption facilities, +and is completely decoupled from any user-interface; for an end-user to make +use of Tox, they need a Tox client. Fast-forward a few years to today, and +there exist several independent Tox client projects, and the original Tox core +library implementation continues to improve. Tox (both core library and +clients) has thousands of users, hundreds of contributors, and the project +shows no sign of slowing down. + +Tox is a FOSS (Free and Open Source) project. All Tox code is open source and +all development occurs in the open. Tox is developed by volunteer developers +who spend their free time on it, believing in the idea of the project. Tox is +not a company or any other legal organization. Currently we don't accept +donations as a project, but you are welcome to reach out to developers +individually. + +## Contact + +This website and other infrastructure such as wiki, blog, etc. are maintained +by some of the long-time contributors of Tox. If you have a legal question, or +if you notice something is wrong with tox.chat servers, or you find an outdated +information on the one of tox.chat websites -- you can send an email to our +[distribution list](mailto:leadership@tox.chat). Please note that this list is +not the right place to ask for general user support. All such emails would +simply be ignored. Please use our [mailing +lists](https://lists.tox.chat/listinfo) or the [Reddit +forums](https://www.reddit.com/r/projecttox/) for general user support. + +For the reference, here is the list of the said long-time Tox contributors +running the infrastructure: + +- [Impyy](mailto:impyy@tox.chat) +- [irungentoo](mailto:irungentoo@tox.chat) +- [Jfreegman](mailto:JFreegman@tox.chat) +- [mannol](mailto:mannol@tox.chat) +- [nurupo](mailto:nurupo@tox.chat) +- [oranges](mailto:oranges@tox.chat) +- [stal](mailto:stal@tox.chat) diff --git a/content/website/hm/hm-test.de.md b/content/website/hm/hm-test.de.md new file mode 100644 index 0000000..3ada38c --- /dev/null +++ b/content/website/hm/hm-test.de.md @@ -0,0 +1,4 @@ +Title: hm test + +lalala + diff --git a/content/website/hm/hm-test.en.md b/content/website/hm/hm-test.en.md new file mode 100644 index 0000000..3ada38c --- /dev/null +++ b/content/website/hm/hm-test.en.md @@ -0,0 +1,4 @@ +Title: hm test + +lalala + diff --git a/content/website/hm/hm-test2.en.md b/content/website/hm/hm-test2.en.md new file mode 100644 index 0000000..7055496 --- /dev/null +++ b/content/website/hm/hm-test2.en.md @@ -0,0 +1,4 @@ +Title: hm test2 + +lalala + diff --git a/content/website/test.de.md b/content/website/test.de.md new file mode 100644 index 0000000..98e5298 --- /dev/null +++ b/content/website/test.de.md @@ -0,0 +1,4 @@ +Title: de! + +de de de + diff --git a/content/website/test.en.md b/content/website/test.en.md new file mode 100644 index 0000000..75a068d --- /dev/null +++ b/content/website/test.en.md @@ -0,0 +1,4 @@ +Title: test page + +Just a test page, ok? + diff --git a/i18n-add-language.sh b/i18n-add-language.sh new file mode 100755 index 0000000..5fd8e51 --- /dev/null +++ b/i18n-add-language.sh @@ -0,0 +1,5 @@ +#!/usr/bin/env bash + +export TZ=UTC + +pybabel init -i themes/i18n/messages.pot -d themes/i18n/translations -l $1 diff --git a/i18n-compile-po.sh b/i18n-compile-po.sh new file mode 100755 index 0000000..5c201d9 --- /dev/null +++ b/i18n-compile-po.sh @@ -0,0 +1,5 @@ +#!/usr/bin/env bash + +export TZ=UTC + +pybabel compile -d themes/i18n/translations diff --git a/i18n-extract-messages.sh b/i18n-extract-messages.sh new file mode 100755 index 0000000..f4ecf8b --- /dev/null +++ b/i18n-extract-messages.sh @@ -0,0 +1,27 @@ +#!/usr/bin/env bash + +export TZ=UTC + +if [ -e themes/i18n/messages.pot ]; then + mv themes/i18n/messages.pot themes/i18n/messages.pot.old +fi + +pybabel extract --msgid-bugs-address="https://github.com/Tox/tox.chat/issues" \ + --copyright-holder="Project Tox Website Contributors" \ + --project="Tox Website" \ + --version="(https://tox.chat)" \ + --sort-by-file \ + -F themes/i18n/babel.cfg \ + -o themes/i18n/messages.pot \ + . + +if [ -e themes/i18n/messages.pot.old ]; then + if diff -u <(sed '/POT-Creation-Date/d' themes/i18n/messages.pot) <(sed '/POT-Creation-Date/d' themes/i18n/messages.pot.old); then + echo "No translation strings changed, keeping the old POT" + mv themes/i18n/messages.pot.old themes/i18n/messages.pot + else + echo "Translation strings changed, using the new POT" + rm themes/i18n/messages.pot.old + fi +fi + diff --git a/i18n-update-po.sh b/i18n-update-po.sh new file mode 100755 index 0000000..97a13ae --- /dev/null +++ b/i18n-update-po.sh @@ -0,0 +1,10 @@ +#!/usr/bin/env bash + +export TZ=UTC + +pybabel update -i themes/i18n/messages.pot -d themes/i18n/translations + +for file in themes/i18n/translations/*/LC_MESSAGES/*.po; do + sed -i '/^#~/,+2d' $file +done + diff --git a/jinja/__init__.py b/jinja/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/jinja/extensions/__init__.py b/jinja/extensions/__init__.py new file mode 100644 index 0000000..e1e5b8e --- /dev/null +++ b/jinja/extensions/__init__.py @@ -0,0 +1,29 @@ +import os +import sys + +modules = [] + +this_dir = os.path.dirname(os.path.abspath(__file__)) +sys.path.append(this_dir) +for module in os.listdir(this_dir): + # avoid '__pycache__' and such + if module.startswith('_'): + continue + module_path = os.path.join(os.path.join(this_dir, module)) + if not os.path.isdir(module_path): + continue + # make sure both the module/module.py and module/__init__.py are present + module_main_file = '{}.py'.format(os.path.join(module_path, module)) + module_init_file = '{}.py'.format(os.path.join(module_path, '__init__')) + if not os.path.isfile(module_main_file): + raise Exception("Can't find {} file".format(module_main_file)) + if not os.path.isfile(module_init_file): + raise Exception("Can't find {} file".format(module_init_file)) + __import__('{}.{}'.format(module, module)) + modules.append(module) + +def get_extensions(): + result = [] + for m in modules: + result.append('{}.{}.{}Extension'.format(m, m, m.capitalize())) + return result diff --git a/jinja/extensions/debug/__init__.py b/jinja/extensions/debug/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/jinja/extensions/debug/debug.py b/jinja/extensions/debug/debug.py new file mode 100644 index 0000000..432f2d0 --- /dev/null +++ b/jinja/extensions/debug/debug.py @@ -0,0 +1,60 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- # + +# From https://github.com/pallets/jinja/pull/798 +# Under Jinja's BSD license. + +import pprint + +from jinja2 import nodes +from jinja2.ext import Extension +from jinja2.nodes import ContextReference + + +class DebugExtension(Extension): + """ + A {% debug %} tag that dumps the variables, filters and tests available. + This is roughyl equivalent to the DTL {% debug %} tag, and typical usage + like this: + + 
{% debug %}
+ + produces output like this: + + {'context': {'_': , + 'csrf_token': , + 'cycler': , + ... + 'view': }, + 'filters': ['abs', 'add', 'addslashes', 'attr', 'batch', 'bootstrap', + 'bootstrap_classes', 'bootstrap_horizontal', 'bootstrap_inline', + ... + 'yesno'], + 'tests': ['callable', 'checkbox_field', 'defined', 'divisibleby', 'escaped', + 'even', 'iterable', 'lower', 'mapping', 'multiple_checkbox_field', + ... + 'string', 'undefined', 'upper']} + """ + tags = {'debug'} + + def __init__(self, environment): + super(DebugExtension, self).__init__(environment) + + def parse(self, parser): + lineno = parser.stream.expect('name:debug').lineno + context = ContextReference() + call = self.call_method('_render', [context], lineno=lineno) + return nodes.Output([nodes.MarkSafe(call)]) + + def _render(self, context): + result = { + 'filters': sorted(self.environment.filters.keys()), + 'tests': sorted(self.environment.tests.keys()), + 'context': context.get_all() + } + # + # We set the depth since the intent is basically to show the top few + # names. TODO: provide user control over this? + # + text = pprint.pformat(result, depth=6) + return text diff --git a/jinja/extensions/error/__init__.py b/jinja/extensions/error/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/jinja/extensions/error/error.py b/jinja/extensions/error/error.py new file mode 100644 index 0000000..fdaf603 --- /dev/null +++ b/jinja/extensions/error/error.py @@ -0,0 +1,18 @@ +#!/usr/bin/env python +# -*- coding: utf-8 -*- # + +from jinja2 import nodes +from jinja2.ext import Extension +from jinja2.exceptions import TemplateRuntimeError + +class ErrorExtension(Extension): + tags = set(['error']) + + def parse(self, parser): + lineno = next(parser.stream).lineno + args = [parser.parse_expression()] + return nodes.CallBlock(self.call_method('_error', args), + [], [], []).set_lineno(lineno) + + def _error(self, arg, caller): + raise TemplateRuntimeError(arg) diff --git a/jinja/filters/__init__.py b/jinja/filters/__init__.py new file mode 100644 index 0000000..3c02bd4 --- /dev/null +++ b/jinja/filters/__init__.py @@ -0,0 +1,29 @@ +import os +import sys + +modules = [] + +this_dir = os.path.dirname(os.path.abspath(__file__)) +sys.path.append(this_dir) +for module in os.listdir(this_dir): + # avoid '__pycache__' and such + if module.startswith('_'): + continue + module_path = os.path.join(os.path.join(this_dir, module)) + if not os.path.isdir(module_path): + continue + # make sure both the module/module.py and module/__init__.py are present + module_main_file = '{}.py'.format(os.path.join(module_path, module)) + module_init_file = '{}.py'.format(os.path.join(module_path, '__init__')) + if not os.path.isfile(module_main_file): + raise Exception("Can't find {} file".format(module_main_file)) + if not os.path.isfile(module_init_file): + raise Exception("Can't find {} file".format(module_init_file)) + __import__('{}.{}'.format(module, module)) + modules.append(module) + +def get_filters(): + result = {} + for m in modules: + result[m] = getattr(sys.modules['{}.{}'.format(m, m)], m) + return result diff --git a/jinja/globals/__init__.py b/jinja/globals/__init__.py new file mode 100644 index 0000000..5a782c5 --- /dev/null +++ b/jinja/globals/__init__.py @@ -0,0 +1,29 @@ +import os +import sys + +modules = [] + +this_dir = os.path.dirname(os.path.abspath(__file__)) +sys.path.append(this_dir) +for module in os.listdir(this_dir): + # avoid '__pycache__' and such + if module.startswith('_'): + continue + module_path = os.path.join(os.path.join(this_dir, module)) + if not os.path.isdir(module_path): + continue + # make sure both the module/module.py and module/__init__.py are present + module_main_file = '{}.py'.format(os.path.join(module_path, module)) + module_init_file = '{}.py'.format(os.path.join(module_path, '__init__')) + if not os.path.isfile(module_main_file): + raise Exception("Can't find {} file".format(module_main_file)) + if not os.path.isfile(module_init_file): + raise Exception("Can't find {} file".format(module_init_file)) + __import__('{}.{}'.format(module, module)) + modules.append(module) + +def get_globals(): + result = {} + for m in modules: + result[m] = getattr(sys.modules['{}.{}'.format(m, m)], m) + return result diff --git a/jinja/globals/pelican_content_rel_path/__init__.py b/jinja/globals/pelican_content_rel_path/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/jinja/globals/pelican_content_rel_path/pelican_content_rel_path.py b/jinja/globals/pelican_content_rel_path/pelican_content_rel_path.py new file mode 100644 index 0000000..f0fd619 --- /dev/null +++ b/jinja/globals/pelican_content_rel_path/pelican_content_rel_path.py @@ -0,0 +1,11 @@ +#!/usr/bin/python +import os +from jinja2 import contextfunction + +@contextfunction +def pelican_content_rel_path(context): + if 'article' in context: + return os.path.relpath(context['article'].source_path) + elif 'page' in context: + return os.path.relpath(context['page'].source_path) + return None diff --git a/jinja/globals/template_rel_path/__init__.py b/jinja/globals/template_rel_path/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/jinja/globals/template_rel_path/template_rel_path.py b/jinja/globals/template_rel_path/template_rel_path.py new file mode 100644 index 0000000..c24b647 --- /dev/null +++ b/jinja/globals/template_rel_path/template_rel_path.py @@ -0,0 +1,25 @@ +#!/usr/bin/python +import os +from jinja2.exceptions import TemplateRuntimeError +from jinja2.loaders import FileSystemLoader, PrefixLoader +from jinja2 import contextfunction + +@contextfunction +def template_rel_path(context): + template_dirs = [] + for l in context.environment.loader.loaders: + if isinstance(l, FileSystemLoader): + template_dirs.extend(l.searchpath) + elif isinstance(l, PrefixLoader): + for p, pl in l.mapping.items(): + if isinstance(pl, FileSystemLoader): + template_dirs.extend(pl.searchpath) + template_path = None + for td in template_dirs: + maybe_tp = os.path.join(td, context.name) + if os.path.isfile(maybe_tp): + template_path = maybe_tp + break + if not template_path: + raise TemplateRuntimeError("Couldn't find the template path for {}".format(context.name)) + return os.path.relpath(template_path) diff --git a/jinja/tests/__init__.py b/jinja/tests/__init__.py new file mode 100644 index 0000000..be1297e --- /dev/null +++ b/jinja/tests/__init__.py @@ -0,0 +1,29 @@ +import os +import sys + +modules = [] + +this_dir = os.path.dirname(os.path.abspath(__file__)) +sys.path.append(this_dir) +for module in os.listdir(this_dir): + # avoid '__pycache__' and such + if module.startswith('_'): + continue + module_path = os.path.join(os.path.join(this_dir, module)) + if not os.path.isdir(module_path): + continue + # make sure both the module/module.py and module/__init__.py are present + module_main_file = '{}.py'.format(os.path.join(module_path, module)) + module_init_file = '{}.py'.format(os.path.join(module_path, '__init__')) + if not os.path.isfile(module_main_file): + raise Exception("Can't find {} file".format(module_main_file)) + if not os.path.isfile(module_init_file): + raise Exception("Can't find {} file".format(module_init_file)) + __import__('{}.{}'.format(module, module)) + modules.append(module) + +def get_tests(): + result = {} + for m in modules: + result[m] = getattr(sys.modules['{}.{}'.format(m, m)], m) + return result diff --git a/pelicanconf.py b/pelicanconf.py index 915eafd..71590b1 100644 --- a/pelicanconf.py +++ b/pelicanconf.py @@ -1,40 +1,218 @@ #!/usr/bin/env python # -*- coding: utf-8 -*- # -from __future__ import unicode_literals -AUTHOR = u'Tox' -SITENAME = u'Tox' +# here we define perlican settings. +# read more on available settings and what each of them does at +# http://docs.getpelican.com/en/stable/settings.html#basic-settings -PATH = 'content' +# by default in pelican static pages and the blog share the same root, but we +# want static pages to be generated in the root and blog to go into /blog. +# pelican allows to do this, but it requires redefining paths, which is what +# the majority of the first half of this file does. we also want to be able to +# have global templates, blog templates and website templates in separate +# directories, which is a bit non-obvious to achieve in pelican, but it's still +# possible. in order to achieve this, you should make THEME point to the common +# root of all of your templates and write your jinja templates with +# include/extend statements using URLs starting at this root. also, pelican +# would be expecting blog templates to reside in THEME/templates/, which it +# wouldn't find as there is no such directory, we have the blog templates +# reside in THEME/blog/templates instead, but you can add this path explicitly +# to EXTRA_TEMPLATES_PATHS setting, which pelican would fallback to when +# failing to find the blog templates at the regular path. -TIMEZONE = 'UTC' +# where to find markdown content +PATH = 'content/' +PAGE_PATHS = ['website'] +ARTICLE_PATHS = ['blog'] + +# where to find static files linked in markdown content using {filename} +STATIC_PATHS = ['blog/static'] +# by default pelican expects articles to be placed directly in PATH and will +# treat any subdirectories in there, like the 'blog' subdirectory we have, as +# a category the articles that are in that directory were posted under, which +# is not we want, we don't want pelican to derive blgo post categories based +# on directory structure at all. this setting does that. +USE_FOLDER_AS_CATEGORY = False +# articles are required to have a category set, so if you don't set a category +# pelican sets one for you, 'misc' by default. we'd rather have pelican failing +# if an article author forgot to specify its category, rather than pelican +# interpret it 'ah, you meant the default category', but apparently there is no +# way to make it fail, if you set default category to None it causes some +# internal error in pelican. https://github.com/getpelican/pelican/issues/2323 +DEFAULT_CATEGORY = 'forgot-to-specify-category' + +# output root +OUTPUT_PATH = 'public' + +# grab the URL slug and lang metadata for pages and articles from the markdown +# filename, instead of having to define 'Slug:', etc. metadata in the markdown +# file. the filenames might optionally start with 'yyyy_mm_dd_' purely for +# filename sorting purposes, we don't use that for an article date, the 'Date:' +# metadata inside the markdown file is used for that. The reason why we don't +# use it as a date is that we want to make that part of filename optional, as +# unlike with articles, it doesn't make much sense to prefix pages with date, +# but pelican doesn't allow optional named groups, at least until this fix is +# released: https://github.com/getpelican/pelican/pull/2117 +# note that this regex is used to match against article/pages filenames only, +# moreover filenames with a dropped extension, so if you end it with '\.md' it +# won't match anything! (figured this out the hard way) +FILENAME_METADATA = '(\d{4}-\d{2}-\d{2}_)?(?P.*)\.(?P.*)' + +# capture page's the filepath, so that we could re-create the the direcotry +# structure in the output directory +PATH_METADATA = '{}/(?P.*)\..*\..*'.format(PAGE_PATHS[0]) + +# staic pages go in the root, preserving the source directory structure +PAGE_URL = '{pages_filepath_no_lang_ext}.html' +PAGE_SAVE_AS = PAGE_URL +PAGE_LANG_URL = PAGE_URL +PAGE_LANG_SAVE_AS = PAGE_SAVE_AS + +# blog-y pages go into blog/ +INDEX_SAVE_AS = 'blog/index.html' -DEFAULT_LANG = u'en' +ARTICLE_URL = 'blog/posts/{date:%Y}/{date:%m}/{date:%d}/{slug}/' +ARTICLE_SAVE_AS = 'blog/posts/{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html' +ARTICLE_LANG_URL = ARTICLE_URL +ARTICLE_LANG_SAVE_AS = ARTICLE_SAVE_AS -FEED_ALL_ATOM = None -CATEGORY_FEED_ATOM = None -TRANSLATION_FEED_ATOM = None +DRAFT_URL = 'blog/drafts/{date:%Y}/{date:%m}/{date:%d}/{slug}/' +DRAFT_SAVE_AS = 'blog/drafts/{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html' +DRAFT_LANG_URL = DRAFT_URL +DRAFT_LANG_SAVE_AS = DRAFT_SAVE_AS -DEFAULT_PAGINATION = False +ARCHIVES_SAVE_AS = 'blog/posts/index.html' +YEAR_ARCHIVE_SAVE_AS = 'blog/posts/{date:%Y}/index.html' +MONTH_ARCHIVE_SAVE_AS = 'blog/posts/{date:%Y}/{date:%m}/index.html' +DAY_ARCHIVE_SAVE_AS = 'blog/posts/{date:%Y}/{date:%m}/{date:%d}/index.html' -THEME = "themes/website" +AUTHORS_SAVE_AS = 'blog/authors/index.html' +AUTHOR_URL = 'blog/authors/{slug}/' +AUTHOR_SAVE_AS = 'blog/authors/{slug}/index.html' +CATEGORIES_SAVE_AS = 'blog/categories/index.html' +CATEGORY_URL = 'blog/categories/{slug}/' +CATEGORY_SAVE_AS = 'blog/categories/{slug}/index.html' -# pelican is mainly aimed at blogs and a regular pelican template has only -# a predefined set of files with predefined names which do blog things. -# since we don't need blog things, we override that, making pelican process -# all template files (that don't start with '_') and don't treat them as some -# special blog templates. -DIRECT_TEMPLATES = [] +# we don't use tags, they tend to be heavily misused and not used consistently, +# a single category per post should be enough for keeping things organized. +TAGS_SAVE_AS = '' +TAG_URL = '' +TAG_SAVE_AS = '' + +DEFAULT_PAGINATION = 8 +PAGINATION_PATTERNS = ( + (1, '{base_name}/', '{base_name}/index.html'), + (2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'), +) + +# keeps all urls '/' +SITEURL = '' + +# feeds can't into relative url +FEED_DOMAIN = 'https://tox.chat' + +# blog feed should also go into blog/ +FEED_ALL_ATOM = '' +FEED_ALL_RSS = '' +TRANSLATION_FEED_ATOM = 'blog/feed-%s.atom.xml' +TRANSLATION_FEED_RSS = 'blog/feed-%s.rss.xml' +CATEGORY_FEED_ATOM = 'blog/categories/%s/feed.atom.xml' +CATEGORY_FEED_RSS = 'blog/categories/%s/feed.rss.xml' +AUTHOR_FEED_ATOM = 'blog/authors/%s/feed.atom.xml' +AUTHOR_FEED_RSS = 'blog/authors/%s/feed.rss.xml' + +# used in generation of feeds, without it pelican inserts some generic +# 'Pelican Blog' name +SITENAME = 'Tox Blog' + +TIMEZONE = 'UTC' +DEFAULT_DATE_FORMAT = '%B %-d, %Y' +DEFAULT_LANG = 'en' +SUMMARY_MAX_LENGTH = 120 + +THEME = 'themes' +EXTRA_TEMPLATES_PATHS = ['themes', 'themes/blog/templates'] + +THEME_STATIC_DIR = 'static' +THEME_STATIC_PATHS = ['global/static', 'blog/static', 'website/static'] + +# tell pelican that our template pages reside in themes/website/templates and +# they should go into OUTPUT_PATH. Also preserve the directory structure. Also +# don't process any files or directories that start with '_', those usually +# contain partial templates or macros. TEMPLATE_PAGES = {} import fnmatch import os -TEMPLATES_DIR = THEME + '/templates' +TEMPLATES_DIR = THEME + '/website/templates' for root, dirnames, filenames in os.walk(TEMPLATES_DIR): + dirnames[:] = [d for d in dirnames if not d.startswith('_')] for filename in fnmatch.filter(filenames, '*.html'): - if not filename.startswith("_"): - template = os.path.join(root, filename)[len(TEMPLATES_DIR)+1:] - TEMPLATE_PAGES[template] = template + if not filename.startswith('_'): + template_src = os.path.join(root, filename)[len(THEME)+1:] + template_dst = os.path.join(root, filename)[len(TEMPLATES_DIR)+1:] + print(template_src + ' -> ' + template_dst) + TEMPLATE_PAGES[template_src] = template_dst + + +# add pelican plugins +PLUGINS = [ + 'plugins.jinja_globals_tests.jinja_globals_tests', + 'plugins.i18n_subsites.i18n_subsites' +] + +# plugins.i18n_subsites.i18n_subsites settings. +# here are some sources on using this plugin: +# https://github.com/getpelican/pelican-plugins/tree/master/i18n_subsites +# http://jinja.pocoo.org/docs/2.10/templates/#i18n +# http://mozweb.readthedocs.io/en/latest/reference/l10n.html +I18N_GETTEXT_LOCALEDIR = 'themes/i18n/translations' +I18N_UNTRANSLATED_ARTICLES = 'keep' +I18N_UNTRANSLATED_PAGES = 'keep' +I18N_SUBSITES = { + 'de': {} +} + +# add our own (or 3rd party) jinja extensions, filters, globals, tests, etc. +import sys +sys.path.append('.') + +import jinja.extensions +JINJA_ENVIRONMENT = { + 'extensions': ['jinja2.ext.i18n'] + jinja.extensions.get_extensions() +} +print('JINJA_ENVIRONMENT = {}'.format(JINJA_ENVIRONMENT)) + +import jinja.filters +JINJA_FILTERS = jinja.filters.get_filters() +print('JINJA_FILTERS = {}'.format(JINJA_FILTERS)) + +import jinja.globals +_JINJA_GLOBALS = jinja.globals.get_globals() +print('_JINJA_GLOBALS = {}'.format(_JINJA_GLOBALS)) + +import jinja.tests +_JINJA_TESTS = jinja.tests.get_tests() +print('_JINJA_TESTS = {}'.format(_JINJA_TESTS)) + +# markdown options +MARKDOWN = { + # see the list of all available extensions at + # https://python-markdown.github.io/extensions/ + 'extension_configs': { + 'markdown.extensions.extra' : {}, + 'markdown.extensions.sane_lists' : {}, + # no so much for the actual Table of Contents functionality as for + # adding unique ids to html headers generated from Markdown, e.g. + #

, so that we could refer to them with anchors, as + # well as for adding ¶ permalinks + 'markdown.extensions.toc': {'permalink': True}, + }, + 'output_format': 'html5', +} + +# non-pelican settings, used by our templates +GITHUB_URL = 'https://github.com/Tox/tox.chat' diff --git a/plugins/__init__.py b/plugins/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/plugins/i18n_subsites/LICENSE b/plugins/i18n_subsites/LICENSE new file mode 100644 index 0000000..dba13ed --- /dev/null +++ b/plugins/i18n_subsites/LICENSE @@ -0,0 +1,661 @@ + GNU AFFERO GENERAL PUBLIC LICENSE + Version 3, 19 November 2007 + + Copyright (C) 2007 Free Software Foundation, Inc. + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The GNU Affero General Public License is a free, copyleft license for +software and other kinds of works, specifically designed to ensure +cooperation with the community in the case of network server software. + + The licenses for most software and other practical works are designed +to take away your freedom to share and change the works. By contrast, +our General Public Licenses are intended to guarantee your freedom to +share and change all versions of a program--to make sure it remains free +software for all its users. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +them if you wish), that you receive source code or can get it if you +want it, that you can change the software or use pieces of it in new +free programs, and that you know you can do these things. + + Developers that use our General Public Licenses protect your rights +with two steps: (1) assert copyright on the software, and (2) offer +you this License which gives you legal permission to copy, distribute +and/or modify the software. + + A secondary benefit of defending all users' freedom is that +improvements made in alternate versions of the program, if they +receive widespread use, become available for other developers to +incorporate. Many developers of free software are heartened and +encouraged by the resulting cooperation. However, in the case of +software used on network servers, this result may fail to come about. +The GNU General Public License permits making a modified version and +letting the public access it on a server without ever releasing its +source code to the public. + + The GNU Affero General Public License is designed specifically to +ensure that, in such cases, the modified source code becomes available +to the community. It requires the operator of a network server to +provide the source code of the modified version running there to the +users of that server. Therefore, public use of a modified version, on +a publicly accessible server, gives the public access to the source +code of the modified version. + + An older license, called the Affero General Public License and +published by Affero, was designed to accomplish similar goals. This is +a different license, not a version of the Affero GPL, but Affero has +released a new version of the Affero GPL which permits relicensing under +this license. + + The precise terms and conditions for copying, distribution and +modification follow. + + TERMS AND CONDITIONS + + 0. Definitions. + + "This License" refers to version 3 of the GNU Affero General Public License. + + "Copyright" also means copyright-like laws that apply to other kinds of +works, such as semiconductor masks. + + "The Program" refers to any copyrightable work licensed under this +License. Each licensee is addressed as "you". "Licensees" and +"recipients" may be individuals or organizations. + + To "modify" a work means to copy from or adapt all or part of the work +in a fashion requiring copyright permission, other than the making of an +exact copy. The resulting work is called a "modified version" of the +earlier work or a work "based on" the earlier work. + + A "covered work" means either the unmodified Program or a work based +on the Program. + + To "propagate" a work means to do anything with it that, without +permission, would make you directly or secondarily liable for +infringement under applicable copyright law, except executing it on a +computer or modifying a private copy. Propagation includes copying, +distribution (with or without modification), making available to the +public, and in some countries other activities as well. + + To "convey" a work means any kind of propagation that enables other +parties to make or receive copies. Mere interaction with a user through +a computer network, with no transfer of a copy, is not conveying. + + An interactive user interface displays "Appropriate Legal Notices" +to the extent that it includes a convenient and prominently visible +feature that (1) displays an appropriate copyright notice, and (2) +tells the user that there is no warranty for the work (except to the +extent that warranties are provided), that licensees may convey the +work under this License, and how to view a copy of this License. If +the interface presents a list of user commands or options, such as a +menu, a prominent item in the list meets this criterion. + + 1. Source Code. + + The "source code" for a work means the preferred form of the work +for making modifications to it. "Object code" means any non-source +form of a work. + + A "Standard Interface" means an interface that either is an official +standard defined by a recognized standards body, or, in the case of +interfaces specified for a particular programming language, one that +is widely used among developers working in that language. + + The "System Libraries" of an executable work include anything, other +than the work as a whole, that (a) is included in the normal form of +packaging a Major Component, but which is not part of that Major +Component, and (b) serves only to enable use of the work with that +Major Component, or to implement a Standard Interface for which an +implementation is available to the public in source code form. A +"Major Component", in this context, means a major essential component +(kernel, window system, and so on) of the specific operating system +(if any) on which the executable work runs, or a compiler used to +produce the work, or an object code interpreter used to run it. + + The "Corresponding Source" for a work in object code form means all +the source code needed to generate, install, and (for an executable +work) run the object code and to modify the work, including scripts to +control those activities. However, it does not include the work's +System Libraries, or general-purpose tools or generally available free +programs which are used unmodified in performing those activities but +which are not part of the work. For example, Corresponding Source +includes interface definition files associated with source files for +the work, and the source code for shared libraries and dynamically +linked subprograms that the work is specifically designed to require, +such as by intimate data communication or control flow between those +subprograms and other parts of the work. + + The Corresponding Source need not include anything that users +can regenerate automatically from other parts of the Corresponding +Source. + + The Corresponding Source for a work in source code form is that +same work. + + 2. Basic Permissions. + + All rights granted under this License are granted for the term of +copyright on the Program, and are irrevocable provided the stated +conditions are met. This License explicitly affirms your unlimited +permission to run the unmodified Program. The output from running a +covered work is covered by this License only if the output, given its +content, constitutes a covered work. This License acknowledges your +rights of fair use or other equivalent, as provided by copyright law. + + You may make, run and propagate covered works that you do not +convey, without conditions so long as your license otherwise remains +in force. You may convey covered works to others for the sole purpose +of having them make modifications exclusively for you, or provide you +with facilities for running those works, provided that you comply with +the terms of this License in conveying all material for which you do +not control copyright. Those thus making or running the covered works +for you must do so exclusively on your behalf, under your direction +and control, on terms that prohibit them from making any copies of +your copyrighted material outside their relationship with you. + + Conveying under any other circumstances is permitted solely under +the conditions stated below. Sublicensing is not allowed; section 10 +makes it unnecessary. + + 3. Protecting Users' Legal Rights From Anti-Circumvention Law. + + No covered work shall be deemed part of an effective technological +measure under any applicable law fulfilling obligations under article +11 of the WIPO copyright treaty adopted on 20 December 1996, or +similar laws prohibiting or restricting circumvention of such +measures. + + When you convey a covered work, you waive any legal power to forbid +circumvention of technological measures to the extent such circumvention +is effected by exercising rights under this License with respect to +the covered work, and you disclaim any intention to limit operation or +modification of the work as a means of enforcing, against the work's +users, your or third parties' legal rights to forbid circumvention of +technological measures. + + 4. Conveying Verbatim Copies. + + You may convey verbatim copies of the Program's source code as you +receive it, in any medium, provided that you conspicuously and +appropriately publish on each copy an appropriate copyright notice; +keep intact all notices stating that this License and any +non-permissive terms added in accord with section 7 apply to the code; +keep intact all notices of the absence of any warranty; and give all +recipients a copy of this License along with the Program. + + You may charge any price or no price for each copy that you convey, +and you may offer support or warranty protection for a fee. + + 5. Conveying Modified Source Versions. + + You may convey a work based on the Program, or the modifications to +produce it from the Program, in the form of source code under the +terms of section 4, provided that you also meet all of these conditions: + + a) The work must carry prominent notices stating that you modified + it, and giving a relevant date. + + b) The work must carry prominent notices stating that it is + released under this License and any conditions added under section + 7. This requirement modifies the requirement in section 4 to + "keep intact all notices". + + c) You must license the entire work, as a whole, under this + License to anyone who comes into possession of a copy. This + License will therefore apply, along with any applicable section 7 + additional terms, to the whole of the work, and all its parts, + regardless of how they are packaged. This License gives no + permission to license the work in any other way, but it does not + invalidate such permission if you have separately received it. + + d) If the work has interactive user interfaces, each must display + Appropriate Legal Notices; however, if the Program has interactive + interfaces that do not display Appropriate Legal Notices, your + work need not make them do so. + + A compilation of a covered work with other separate and independent +works, which are not by their nature extensions of the covered work, +and which are not combined with it such as to form a larger program, +in or on a volume of a storage or distribution medium, is called an +"aggregate" if the compilation and its resulting copyright are not +used to limit the access or legal rights of the compilation's users +beyond what the individual works permit. Inclusion of a covered work +in an aggregate does not cause this License to apply to the other +parts of the aggregate. + + 6. Conveying Non-Source Forms. + + You may convey a covered work in object code form under the terms +of sections 4 and 5, provided that you also convey the +machine-readable Corresponding Source under the terms of this License, +in one of these ways: + + a) Convey the object code in, or embodied in, a physical product + (including a physical distribution medium), accompanied by the + Corresponding Source fixed on a durable physical medium + customarily used for software interchange. + + b) Convey the object code in, or embodied in, a physical product + (including a physical distribution medium), accompanied by a + written offer, valid for at least three years and valid for as + long as you offer spare parts or customer support for that product + model, to give anyone who possesses the object code either (1) a + copy of the Corresponding Source for all the software in the + product that is covered by this License, on a durable physical + medium customarily used for software interchange, for a price no + more than your reasonable cost of physically performing this + conveying of source, or (2) access to copy the + Corresponding Source from a network server at no charge. + + c) Convey individual copies of the object code with a copy of the + written offer to provide the Corresponding Source. This + alternative is allowed only occasionally and noncommercially, and + only if you received the object code with such an offer, in accord + with subsection 6b. + + d) Convey the object code by offering access from a designated + place (gratis or for a charge), and offer equivalent access to the + Corresponding Source in the same way through the same place at no + further charge. You need not require recipients to copy the + Corresponding Source along with the object code. If the place to + copy the object code is a network server, the Corresponding Source + may be on a different server (operated by you or a third party) + that supports equivalent copying facilities, provided you maintain + clear directions next to the object code saying where to find the + Corresponding Source. Regardless of what server hosts the + Corresponding Source, you remain obligated to ensure that it is + available for as long as needed to satisfy these requirements. + + e) Convey the object code using peer-to-peer transmission, provided + you inform other peers where the object code and Corresponding + Source of the work are being offered to the general public at no + charge under subsection 6d. + + A separable portion of the object code, whose source code is excluded +from the Corresponding Source as a System Library, need not be +included in conveying the object code work. + + A "User Product" is either (1) a "consumer product", which means any +tangible personal property which is normally used for personal, family, +or household purposes, or (2) anything designed or sold for incorporation +into a dwelling. In determining whether a product is a consumer product, +doubtful cases shall be resolved in favor of coverage. For a particular +product received by a particular user, "normally used" refers to a +typical or common use of that class of product, regardless of the status +of the particular user or of the way in which the particular user +actually uses, or expects or is expected to use, the product. A product +is a consumer product regardless of whether the product has substantial +commercial, industrial or non-consumer uses, unless such uses represent +the only significant mode of use of the product. + + "Installation Information" for a User Product means any methods, +procedures, authorization keys, or other information required to install +and execute modified versions of a covered work in that User Product from +a modified version of its Corresponding Source. The information must +suffice to ensure that the continued functioning of the modified object +code is in no case prevented or interfered with solely because +modification has been made. + + If you convey an object code work under this section in, or with, or +specifically for use in, a User Product, and the conveying occurs as +part of a transaction in which the right of possession and use of the +User Product is transferred to the recipient in perpetuity or for a +fixed term (regardless of how the transaction is characterized), the +Corresponding Source conveyed under this section must be accompanied +by the Installation Information. But this requirement does not apply +if neither you nor any third party retains the ability to install +modified object code on the User Product (for example, the work has +been installed in ROM). + + The requirement to provide Installation Information does not include a +requirement to continue to provide support service, warranty, or updates +for a work that has been modified or installed by the recipient, or for +the User Product in which it has been modified or installed. Access to a +network may be denied when the modification itself materially and +adversely affects the operation of the network or violates the rules and +protocols for communication across the network. + + Corresponding Source conveyed, and Installation Information provided, +in accord with this section must be in a format that is publicly +documented (and with an implementation available to the public in +source code form), and must require no special password or key for +unpacking, reading or copying. + + 7. Additional Terms. + + "Additional permissions" are terms that supplement the terms of this +License by making exceptions from one or more of its conditions. +Additional permissions that are applicable to the entire Program shall +be treated as though they were included in this License, to the extent +that they are valid under applicable law. If additional permissions +apply only to part of the Program, that part may be used separately +under those permissions, but the entire Program remains governed by +this License without regard to the additional permissions. + + When you convey a copy of a covered work, you may at your option +remove any additional permissions from that copy, or from any part of +it. (Additional permissions may be written to require their own +removal in certain cases when you modify the work.) You may place +additional permissions on material, added by you to a covered work, +for which you have or can give appropriate copyright permission. + + Notwithstanding any other provision of this License, for material you +add to a covered work, you may (if authorized by the copyright holders of +that material) supplement the terms of this License with terms: + + a) Disclaiming warranty or limiting liability differently from the + terms of sections 15 and 16 of this License; or + + b) Requiring preservation of specified reasonable legal notices or + author attributions in that material or in the Appropriate Legal + Notices displayed by works containing it; or + + c) Prohibiting misrepresentation of the origin of that material, or + requiring that modified versions of such material be marked in + reasonable ways as different from the original version; or + + d) Limiting the use for publicity purposes of names of licensors or + authors of the material; or + + e) Declining to grant rights under trademark law for use of some + trade names, trademarks, or service marks; or + + f) Requiring indemnification of licensors and authors of that + material by anyone who conveys the material (or modified versions of + it) with contractual assumptions of liability to the recipient, for + any liability that these contractual assumptions directly impose on + those licensors and authors. + + All other non-permissive additional terms are considered "further +restrictions" within the meaning of section 10. If the Program as you +received it, or any part of it, contains a notice stating that it is +governed by this License along with a term that is a further +restriction, you may remove that term. If a license document contains +a further restriction but permits relicensing or conveying under this +License, you may add to a covered work material governed by the terms +of that license document, provided that the further restriction does +not survive such relicensing or conveying. + + If you add terms to a covered work in accord with this section, you +must place, in the relevant source files, a statement of the +additional terms that apply to those files, or a notice indicating +where to find the applicable terms. + + Additional terms, permissive or non-permissive, may be stated in the +form of a separately written license, or stated as exceptions; +the above requirements apply either way. + + 8. Termination. + + You may not propagate or modify a covered work except as expressly +provided under this License. Any attempt otherwise to propagate or +modify it is void, and will automatically terminate your rights under +this License (including any patent licenses granted under the third +paragraph of section 11). + + However, if you cease all violation of this License, then your +license from a particular copyright holder is reinstated (a) +provisionally, unless and until the copyright holder explicitly and +finally terminates your license, and (b) permanently, if the copyright +holder fails to notify you of the violation by some reasonable means +prior to 60 days after the cessation. + + Moreover, your license from a particular copyright holder is +reinstated permanently if the copyright holder notifies you of the +violation by some reasonable means, this is the first time you have +received notice of violation of this License (for any work) from that +copyright holder, and you cure the violation prior to 30 days after +your receipt of the notice. + + Termination of your rights under this section does not terminate the +licenses of parties who have received copies or rights from you under +this License. If your rights have been terminated and not permanently +reinstated, you do not qualify to receive new licenses for the same +material under section 10. + + 9. Acceptance Not Required for Having Copies. + + You are not required to accept this License in order to receive or +run a copy of the Program. Ancillary propagation of a covered work +occurring solely as a consequence of using peer-to-peer transmission +to receive a copy likewise does not require acceptance. However, +nothing other than this License grants you permission to propagate or +modify any covered work. These actions infringe copyright if you do +not accept this License. Therefore, by modifying or propagating a +covered work, you indicate your acceptance of this License to do so. + + 10. Automatic Licensing of Downstream Recipients. + + Each time you convey a covered work, the recipient automatically +receives a license from the original licensors, to run, modify and +propagate that work, subject to this License. You are not responsible +for enforcing compliance by third parties with this License. + + An "entity transaction" is a transaction transferring control of an +organization, or substantially all assets of one, or subdividing an +organization, or merging organizations. If propagation of a covered +work results from an entity transaction, each party to that +transaction who receives a copy of the work also receives whatever +licenses to the work the party's predecessor in interest had or could +give under the previous paragraph, plus a right to possession of the +Corresponding Source of the work from the predecessor in interest, if +the predecessor has it or can get it with reasonable efforts. + + You may not impose any further restrictions on the exercise of the +rights granted or affirmed under this License. For example, you may +not impose a license fee, royalty, or other charge for exercise of +rights granted under this License, and you may not initiate litigation +(including a cross-claim or counterclaim in a lawsuit) alleging that +any patent claim is infringed by making, using, selling, offering for +sale, or importing the Program or any portion of it. + + 11. Patents. + + A "contributor" is a copyright holder who authorizes use under this +License of the Program or a work on which the Program is based. The +work thus licensed is called the contributor's "contributor version". + + A contributor's "essential patent claims" are all patent claims +owned or controlled by the contributor, whether already acquired or +hereafter acquired, that would be infringed by some manner, permitted +by this License, of making, using, or selling its contributor version, +but do not include claims that would be infringed only as a +consequence of further modification of the contributor version. For +purposes of this definition, "control" includes the right to grant +patent sublicenses in a manner consistent with the requirements of +this License. + + Each contributor grants you a non-exclusive, worldwide, royalty-free +patent license under the contributor's essential patent claims, to +make, use, sell, offer for sale, import and otherwise run, modify and +propagate the contents of its contributor version. + + In the following three paragraphs, a "patent license" is any express +agreement or commitment, however denominated, not to enforce a patent +(such as an express permission to practice a patent or covenant not to +sue for patent infringement). To "grant" such a patent license to a +party means to make such an agreement or commitment not to enforce a +patent against the party. + + If you convey a covered work, knowingly relying on a patent license, +and the Corresponding Source of the work is not available for anyone +to copy, free of charge and under the terms of this License, through a +publicly available network server or other readily accessible means, +then you must either (1) cause the Corresponding Source to be so +available, or (2) arrange to deprive yourself of the benefit of the +patent license for this particular work, or (3) arrange, in a manner +consistent with the requirements of this License, to extend the patent +license to downstream recipients. "Knowingly relying" means you have +actual knowledge that, but for the patent license, your conveying the +covered work in a country, or your recipient's use of the covered work +in a country, would infringe one or more identifiable patents in that +country that you have reason to believe are valid. + + If, pursuant to or in connection with a single transaction or +arrangement, you convey, or propagate by procuring conveyance of, a +covered work, and grant a patent license to some of the parties +receiving the covered work authorizing them to use, propagate, modify +or convey a specific copy of the covered work, then the patent license +you grant is automatically extended to all recipients of the covered +work and works based on it. + + A patent license is "discriminatory" if it does not include within +the scope of its coverage, prohibits the exercise of, or is +conditioned on the non-exercise of one or more of the rights that are +specifically granted under this License. You may not convey a covered +work if you are a party to an arrangement with a third party that is +in the business of distributing software, under which you make payment +to the third party based on the extent of your activity of conveying +the work, and under which the third party grants, to any of the +parties who would receive the covered work from you, a discriminatory +patent license (a) in connection with copies of the covered work +conveyed by you (or copies made from those copies), or (b) primarily +for and in connection with specific products or compilations that +contain the covered work, unless you entered into that arrangement, +or that patent license was granted, prior to 28 March 2007. + + Nothing in this License shall be construed as excluding or limiting +any implied license or other defenses to infringement that may +otherwise be available to you under applicable patent law. + + 12. No Surrender of Others' Freedom. + + If conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot convey a +covered work so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you may +not convey it at all. For example, if you agree to terms that obligate you +to collect a royalty for further conveying from those to whom you convey +the Program, the only way you could satisfy both those terms and this +License would be to refrain entirely from conveying the Program. + + 13. Remote Network Interaction; Use with the GNU General Public License. + + Notwithstanding any other provision of this License, if you modify the +Program, your modified version must prominently offer all users +interacting with it remotely through a computer network (if your version +supports such interaction) an opportunity to receive the Corresponding +Source of your version by providing access to the Corresponding Source +from a network server at no charge, through some standard or customary +means of facilitating copying of software. This Corresponding Source +shall include the Corresponding Source for any work covered by version 3 +of the GNU General Public License that is incorporated pursuant to the +following paragraph. + + Notwithstanding any other provision of this License, you have +permission to link or combine any covered work with a work licensed +under version 3 of the GNU General Public License into a single +combined work, and to convey the resulting work. The terms of this +License will continue to apply to the part which is the covered work, +but the work with which it is combined will remain governed by version +3 of the GNU General Public License. + + 14. Revised Versions of this License. + + The Free Software Foundation may publish revised and/or new versions of +the GNU Affero General Public License from time to time. Such new versions +will be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + + Each version is given a distinguishing version number. If the +Program specifies that a certain numbered version of the GNU Affero General +Public License "or any later version" applies to it, you have the +option of following the terms and conditions either of that numbered +version or of any later version published by the Free Software +Foundation. If the Program does not specify a version number of the +GNU Affero General Public License, you may choose any version ever published +by the Free Software Foundation. + + If the Program specifies that a proxy can decide which future +versions of the GNU Affero General Public License can be used, that proxy's +public statement of acceptance of a version permanently authorizes you +to choose that version for the Program. + + Later license versions may give you additional or different +permissions. However, no additional obligations are imposed on any +author or copyright holder as a result of your choosing to follow a +later version. + + 15. Disclaimer of Warranty. + + THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY +APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT +HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY +OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, +THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM +IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF +ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. Limitation of Liability. + + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS +THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY +GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE +USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF +DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD +PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), +EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF +SUCH DAMAGES. + + 17. Interpretation of Sections 15 and 16. + + If the disclaimer of warranty and limitation of liability provided +above cannot be given local legal effect according to their terms, +reviewing courts shall apply local law that most closely approximates +an absolute waiver of all civil liability in connection with the +Program, unless a warranty or assumption of liability accompanies a +copy of the Program in return for a fee. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +state the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with this program. If not, see . + +Also add information on how to contact you by electronic and paper mail. + + If your software can interact with users remotely through a computer +network, you should also make sure that it provides a way for users to +get its source. For example, if your program is a web application, its +interface could display a "Source" link that leads users to an archive +of the code. There are many ways you could offer source, and different +solutions will be better for different programs; see section 13 for the +specific requirements. + + You should also get your employer (if you work as a programmer) or school, +if any, to sign a "copyright disclaimer" for the program, if necessary. +For more information on this, and how to apply and follow the GNU AGPL, see +. diff --git a/plugins/i18n_subsites/README.rst b/plugins/i18n_subsites/README.rst new file mode 100644 index 0000000..340109b --- /dev/null +++ b/plugins/i18n_subsites/README.rst @@ -0,0 +1,165 @@ +======================= + I18N Sub-sites Plugin +======================= + +This plugin extends the translations functionality by creating +internationalized sub-sites for the default site. + +This plugin is designed for Pelican 3.4 and later. + +What it does +============ + +1. When the content of the main site is being generated, the settings + are saved and the generation stops when content is ready to be + written. While reading source files and generating content objects, + the output queue is modified in certain ways: + + - translations that will appear as native in a different (sub-)site + will be removed + - untranslated articles will be transformed to drafts if + ``I18N_UNTRANSLATED_ARTICLES`` is ``'hide'`` (default), removed if + ``'remove'`` or kept as they are if ``'keep'``. + - untranslated pages will be transformed into hidden pages if + ``I18N_UNTRANSLATED_PAGES`` is ``'hide'`` (default), removed if + ``'remove'`` or kept as they are if ``'keep'``.'' + - additional content manipulation similar to articles and pages can + be specified for custom generators in the ``I18N_GENERATOR_INFO`` + setting. + +2. For each language specified in the ``I18N_SUBSITES`` dictionary the + settings overrides are applied to the settings from the main site + and a new sub-site is generated in the same way as with the main + site until content is ready to be written. +3. When all (sub-)sites are waiting for content writing, all removed + contents, translations and static files are interlinked across the + (sub-)sites. +4. Finally, all the output is written. + +Setting it up +============= + +For each extra used language code, a language-specific settings overrides +dictionary must be given (but can be empty) in the ``I18N_SUBSITES`` dictionary + +.. code-block:: python + + PLUGINS = ['i18n_subsites', ...] + + # mapping: language_code -> settings_overrides_dict + I18N_SUBSITES = { + 'cz': { + 'SITENAME': 'Hezkej blog', + } + } + +You must also have the following in your pelican configuration + +.. code-block:: python + JINJA_ENVIRONMENT = { + 'extensions': ['jinja2.ext.i18n'], + } + + + +Default and special overrides +----------------------------- +The settings overrides may contain arbitrary settings, however, there +are some that are handled in a special way: + +``SITEURL`` + Any overrides to this setting should ensure that there is some level + of hierarchy between all (sub-)sites, because Pelican makes all URLs + relative to ``SITEURL`` and the plugin can only cross-link between + the sites using this hierarchy. For instance, with the main site + ``http://example.com`` a sub-site ``http://example.com/de`` will + work, but ``http://de.example.com`` will not. If not overridden, the + language code (the language identifier used in the ``lang`` + metadata) is appended to the main ``SITEURL`` for each sub-site. +``OUTPUT_PATH``, ``CACHE_PATH`` + If not overridden, the language code is appended as with ``SITEURL``. + Separate cache paths are required as parser results depend on the locale. +``STATIC_PATHS``, ``THEME_STATIC_PATHS`` + If not overridden, they are set to ``[]`` and all links to static + files are cross-linked to the main site. +``THEME``, ``THEME_STATIC_DIR`` + If overridden, the logic with ``THEME_STATIC_PATHS`` does not apply. +``DEFAULT_LANG`` + This should not be overridden as the plugin changes it to the + language code of each sub-site to change what is perceived as translations. + +Localizing templates +-------------------- + +Most importantly, this plugin can use localized templates for each +sub-site. There are two approaches to having the templates localized: + +- You can set a different ``THEME`` override for each language in + ``I18N_SUBSITES``, e.g. by making a copy of a theme ``my_theme`` to + ``my_theme_lang`` and then editing the templates in the new + localized theme. This approach means you don't have to deal with + gettext ``*.po`` files, but it is harder to maintain over time. +- You use only one theme and localize the templates using the + `jinja2.ext.i18n Jinja2 extension + `_. For a kickstart + read this `guide <./localizing_using_jinja2.rst>`_. + +Additional context variables +............................ + +It may be convenient to add language buttons to your theme in addition +to the translation links of articles and pages. These buttons could, +for example, point to the ``SITEURL`` of each (sub-)site. For this +reason the plugin adds these variables to the template context: + +``main_lang`` + The language of the main site — the original ``DEFAULT_LANG`` +``main_siteurl`` + The ``SITEURL`` of the main site — the original ``SITEURL`` +``lang_siteurls`` + An ordered dictionary, mapping all used languages to their + ``SITEURL``. The ``main_lang`` is the first key with ``main_siteurl`` + as the value. This dictionary is useful for implementing global + language buttons that show the language of the currently viewed + (sub-)site too. +``extra_siteurls`` + An ordered dictionary, subset of ``lang_siteurls``, the current + ``DEFAULT_LANG`` of the rendered (sub-)site is not included, so for + each (sub-)site ``set(extra_siteurls) == set(lang_siteurls) - + set([DEFAULT_LANG])``. This dictionary is useful for implementing + global language buttons that do not show the current language. +``relpath_to_site`` + A function that returns a relative path from the first (sub-)site to + the second (sub-)site where the (sub-)sites are identified by the + language codes given as two arguments. + +If you don't like the default ordering of the ordered dictionaries, +use a Jinja2 filter to alter the ordering. + +All the siteurls above are always absolute even in the case of +``RELATIVE_URLS == True`` (it would be to complicated to replicate the +Pelican internals for local siteurls), so you may rather use something +like ``{{ SITEURL }}/{{ relpath_to_site(DEFAULT_LANG, main_lang }}`` +to link to the main site. + +This short `howto <./implementing_language_buttons.rst>`_ shows two +example implementations of language buttons. + +Usage notes +=========== +- It is **mandatory** to specify ``lang`` metadata for each article + and page as ``DEFAULT_LANG`` is later changed for each sub-site, so + content without ``lang`` metadata would be rendered in every + (sub-)site. +- As with the original translations functionality, ``slug`` metadata + is used to group translations. It is therefore often convenient to + compensate for this by overriding the content URL (which defaults to + slug) using the ``url`` and ``save_as`` metadata. You could also + give articles e.g. ``name`` metadata and use it in ``ARTICLE_URL = + '{name}.html'``. + +Development +=========== + +- A demo and a test site is in the ``gh-pages`` branch and can be seen + at http://smartass101.github.io/pelican-plugins/ diff --git a/plugins/i18n_subsites/__init__.py b/plugins/i18n_subsites/__init__.py new file mode 100644 index 0000000..7dfbde0 --- /dev/null +++ b/plugins/i18n_subsites/__init__.py @@ -0,0 +1 @@ +from .i18n_subsites import * diff --git a/plugins/i18n_subsites/i18n_subsites.py b/plugins/i18n_subsites/i18n_subsites.py new file mode 100644 index 0000000..388e758 --- /dev/null +++ b/plugins/i18n_subsites/i18n_subsites.py @@ -0,0 +1,450 @@ +"""i18n_subsites plugin creates i18n-ized subsites of the default site + +This plugin is designed for Pelican 3.4 and later +""" + + +import os +import six +import logging +import posixpath + +from copy import copy +from itertools import chain +from operator import attrgetter +from collections import OrderedDict +from contextlib import contextmanager +from six.moves.urllib.parse import urlparse + +import gettext +import locale + +from pelican import signals +from pelican.generators import ArticlesGenerator, PagesGenerator +from pelican.settings import configure_settings +from pelican.contents import Draft + + +# Global vars +_MAIN_SETTINGS = None # settings dict of the main Pelican instance +_MAIN_LANG = None # lang of the main Pelican instance +_MAIN_SITEURL = None # siteurl of the main Pelican instance +_MAIN_STATIC_FILES = None # list of Static instances the main Pelican instance +_SUBSITE_QUEUE = {} # map: lang -> settings overrides +_SITE_DB = OrderedDict() # OrderedDict: lang -> siteurl +_SITES_RELPATH_DB = {} # map: (lang, base_lang) -> relpath +# map: generator -> list of removed contents that need interlinking +_GENERATOR_DB = {} +_NATIVE_CONTENT_URL_DB = {} # map: source_path -> content in its native lang +_LOGGER = logging.getLogger(__name__) + + +@contextmanager +def temporary_locale(temp_locale=None): + '''Enable code to run in a context with a temporary locale + + Resets the locale back when exiting context. + Can set a temporary locale if provided + ''' + orig_locale = locale.setlocale(locale.LC_ALL) + if temp_locale is not None: + locale.setlocale(locale.LC_ALL, temp_locale) + yield + locale.setlocale(locale.LC_ALL, orig_locale) + + +def initialize_dbs(settings): + '''Initialize internal DBs using the Pelican settings dict + + This clears the DBs for e.g. autoreload mode to work + ''' + global _MAIN_SETTINGS, _MAIN_SITEURL, _MAIN_LANG, _SUBSITE_QUEUE + _MAIN_SETTINGS = settings + _MAIN_LANG = settings['DEFAULT_LANG'] + _MAIN_SITEURL = settings['SITEURL'] + _SUBSITE_QUEUE = settings.get('I18N_SUBSITES', {}).copy() + prepare_site_db_and_overrides() + # clear databases in case of autoreload mode + _SITES_RELPATH_DB.clear() + _NATIVE_CONTENT_URL_DB.clear() + _GENERATOR_DB.clear() + + +def prepare_site_db_and_overrides(): + '''Prepare overrides and create _SITE_DB + + _SITE_DB.keys() need to be ready for filter_translations + ''' + _SITE_DB.clear() + _SITE_DB[_MAIN_LANG] = _MAIN_SITEURL + # make sure it works for both root-relative and absolute + main_siteurl = '/' if _MAIN_SITEURL == '' else _MAIN_SITEURL + for lang, overrides in _SUBSITE_QUEUE.items(): + if 'SITEURL' not in overrides: + overrides['SITEURL'] = posixpath.join(main_siteurl, lang) + _SITE_DB[lang] = overrides['SITEURL'] + # default subsite hierarchy + if 'OUTPUT_PATH' not in overrides: + overrides['OUTPUT_PATH'] = os.path.join( + _MAIN_SETTINGS['OUTPUT_PATH'], lang) + if 'CACHE_PATH' not in overrides: + overrides['CACHE_PATH'] = os.path.join( + _MAIN_SETTINGS['CACHE_PATH'], lang) + if 'STATIC_PATHS' not in overrides: + overrides['STATIC_PATHS'] = [] + if ('THEME' not in overrides and 'THEME_STATIC_DIR' not in overrides and + 'THEME_STATIC_PATHS' not in overrides): + relpath = relpath_to_site(lang, _MAIN_LANG) + overrides['THEME_STATIC_DIR'] = posixpath.join( + relpath, _MAIN_SETTINGS['THEME_STATIC_DIR']) + overrides['THEME_STATIC_PATHS'] = [] + # to change what is perceived as translations + overrides['DEFAULT_LANG'] = lang + + +def subscribe_filter_to_signals(settings): + '''Subscribe content filter to requested signals''' + for sig in settings.get('I18N_FILTER_SIGNALS', []): + sig.connect(filter_contents_translations) + + +def initialize_plugin(pelican_obj): + '''Initialize plugin variables and Pelican settings''' + if _MAIN_SETTINGS is None: + initialize_dbs(pelican_obj.settings) + subscribe_filter_to_signals(pelican_obj.settings) + + +def get_site_path(url): + '''Get the path component of an url, excludes siteurl + + also normalizes '' to '/' for relpath to work, + otherwise it could be interpreted as a relative filesystem path + ''' + path = urlparse(url).path + if path == '': + path = '/' + return path + + +def relpath_to_site(lang, target_lang): + '''Get relative path from siteurl of lang to siteurl of base_lang + + the output is cached in _SITES_RELPATH_DB + ''' + path = _SITES_RELPATH_DB.get((lang, target_lang), None) + if path is None: + siteurl = _SITE_DB.get(lang, _MAIN_SITEURL) + target_siteurl = _SITE_DB.get(target_lang, _MAIN_SITEURL) + path = posixpath.relpath(get_site_path(target_siteurl), + get_site_path(siteurl)) + _SITES_RELPATH_DB[(lang, target_lang)] = path + return path + + +def save_generator(generator): + '''Save the generator for later use + + initialize the removed content list + ''' + _GENERATOR_DB[generator] = [] + + +def article2draft(article): + '''Transform an Article to Draft''' + draft = Draft(article._content, article.metadata, article.settings, + article.source_path, article._context) + draft.status = 'draft' + return draft + + +def page2hidden_page(page): + '''Transform a Page to a hidden Page''' + page.status = 'hidden' + return page + + +class GeneratorInspector(object): + '''Inspector of generator instances''' + + generators_info = { + ArticlesGenerator: { + 'translations_lists': ['translations', 'drafts_translations'], + 'contents_lists': [('articles', 'drafts')], + 'hiding_func': article2draft, + 'policy': 'I18N_UNTRANSLATED_ARTICLES', + }, + PagesGenerator: { + 'translations_lists': ['translations', 'hidden_translations'], + 'contents_lists': [('pages', 'hidden_pages')], + 'hiding_func': page2hidden_page, + 'policy': 'I18N_UNTRANSLATED_PAGES', + }, + } + + def __init__(self, generator): + '''Identify the best known class of the generator instance + + The class ''' + self.generator = generator + self.generators_info.update(generator.settings.get( + 'I18N_GENERATORS_INFO', {})) + for cls in generator.__class__.__mro__: + if cls in self.generators_info: + self.info = self.generators_info[cls] + break + else: + self.info = {} + + def translations_lists(self): + '''Iterator over lists of content translations''' + return (getattr(self.generator, name) for name in + self.info.get('translations_lists', [])) + + def contents_list_pairs(self): + '''Iterator over pairs of normal and hidden contents''' + return (tuple(getattr(self.generator, name) for name in names) + for names in self.info.get('contents_lists', [])) + + def hiding_function(self): + '''Function for transforming content to a hidden version''' + hiding_func = self.info.get('hiding_func', lambda x: x) + return hiding_func + + def untranslated_policy(self, default): + '''Get the policy for untranslated content''' + return self.generator.settings.get(self.info.get('policy', None), + default) + + def all_contents(self): + '''Iterator over all contents''' + translations_iterator = chain(*self.translations_lists()) + return chain(translations_iterator, + *(pair[i] for pair in self.contents_list_pairs() + for i in (0, 1))) + + +def filter_contents_translations(generator): + '''Filter the content and translations lists of a generator + + Filters out + 1) translations which will be generated in a different site + 2) content that is not in the language of the currently + generated site but in that of a different site, content in a + language which has no site is generated always. The filtering + method bay be modified by the respective untranslated policy + ''' + inspector = GeneratorInspector(generator) + current_lang = generator.settings['DEFAULT_LANG'] + langs_with_sites = _SITE_DB.keys() + removed_contents = _GENERATOR_DB[generator] + + for translations in inspector.translations_lists(): + for translation in translations[:]: # copy to be able to remove + if translation.lang in langs_with_sites: + translations.remove(translation) + removed_contents.append(translation) + + hiding_func = inspector.hiding_function() + untrans_policy = inspector.untranslated_policy(default='hide') + for (contents, other_contents) in inspector.contents_list_pairs(): + for content in other_contents: # save any hidden native content first + if content.lang == current_lang: # in native lang + # save the native URL attr formatted in the current locale + _NATIVE_CONTENT_URL_DB[content.source_path] = content.url + for content in contents[:]: # copy for removing in loop + if content.lang == current_lang: # in native lang + # save the native URL attr formatted in the current locale + _NATIVE_CONTENT_URL_DB[content.source_path] = content.url + elif content.lang in langs_with_sites and untrans_policy != 'keep': + contents.remove(content) + if untrans_policy == 'hide': + other_contents.append(hiding_func(content)) + elif untrans_policy == 'remove': + removed_contents.append(content) + + +def install_templates_translations(generator): + '''Install gettext translations in the jinja2.Environment + + Only if the 'jinja2.ext.i18n' jinja2 extension is enabled + the translations for the current DEFAULT_LANG are installed. + ''' + if 'JINJA_ENVIRONMENT' in generator.settings: # pelican 3.7+ + jinja_extensions = generator.settings['JINJA_ENVIRONMENT'].get( + 'extensions', []) + else: + jinja_extensions = generator.settings['JINJA_EXTENSIONS'] + + if 'jinja2.ext.i18n' in jinja_extensions: + domain = generator.settings.get('I18N_GETTEXT_DOMAIN', 'messages') + localedir = generator.settings.get('I18N_GETTEXT_LOCALEDIR') + if localedir is None: + localedir = os.path.join(generator.theme, 'translations') + current_lang = generator.settings['DEFAULT_LANG'] + if current_lang == generator.settings.get('I18N_TEMPLATES_LANG', + _MAIN_LANG): + translations = gettext.NullTranslations() + else: + langs = [current_lang] + try: + translations = gettext.translation(domain, localedir, langs) + except (IOError, OSError): + _LOGGER.error(( + "Cannot find translations for language '{}' in '{}' with " + "domain '{}'. Installing NullTranslations.").format( + langs[0], localedir, domain)) + translations = gettext.NullTranslations() + newstyle = generator.settings.get('I18N_GETTEXT_NEWSTYLE', True) + generator.env.install_gettext_translations(translations, newstyle) + + +def add_variables_to_context(generator): + '''Adds useful iterable variables to template context''' + context = generator.context # minimize attr lookup + context['relpath_to_site'] = relpath_to_site + context['main_siteurl'] = _MAIN_SITEURL + context['main_lang'] = _MAIN_LANG + context['lang_siteurls'] = _SITE_DB + current_lang = generator.settings['DEFAULT_LANG'] + extra_siteurls = _SITE_DB.copy() + extra_siteurls.pop(current_lang) + context['extra_siteurls'] = extra_siteurls + + +def interlink_translations(content): + '''Link content to translations in their main language + + so the URL (including localized month names) of the different subsites + will be honored + ''' + lang = content.lang + # sort translations by lang + content.translations.sort(key=attrgetter('lang')) + for translation in content.translations: + relpath = relpath_to_site(lang, translation.lang) + url = _NATIVE_CONTENT_URL_DB[translation.source_path] + translation.override_url = posixpath.join(relpath, url) + + +def interlink_translated_content(generator): + '''Make translations link to the native locations + + for generators that may contain translated content + ''' + inspector = GeneratorInspector(generator) + for content in inspector.all_contents(): + interlink_translations(content) + + +def interlink_removed_content(generator): + '''For all contents removed from generation queue update interlinks + + link to the native location + ''' + current_lang = generator.settings['DEFAULT_LANG'] + for content in _GENERATOR_DB[generator]: + url = _NATIVE_CONTENT_URL_DB[content.source_path] + relpath = relpath_to_site(current_lang, content.lang) + content.override_url = posixpath.join(relpath, url) + + +def interlink_static_files(generator): + '''Add links to static files in the main site if necessary''' + if generator.settings['STATIC_PATHS'] != []: + return # customized STATIC_PATHS + filenames = generator.context['filenames'] # minimize attr lookup + relpath = relpath_to_site(generator.settings['DEFAULT_LANG'], _MAIN_LANG) + for staticfile in _MAIN_STATIC_FILES: + if staticfile.get_relative_source_path() not in filenames: + staticfile = copy(staticfile) # prevent override in main site + staticfile.override_url = posixpath.join(relpath, staticfile.url) + generator.add_source_path(staticfile) + + +def save_main_static_files(static_generator): + '''Save the static files generated for the main site''' + global _MAIN_STATIC_FILES + # test just for current lang as settings change in autoreload mode + if static_generator.settings['DEFAULT_LANG'] == _MAIN_LANG: + _MAIN_STATIC_FILES = static_generator.staticfiles + + +def update_generators(): + '''Update the context of all generators + + Ads useful variables and translations into the template context + and interlink translations + ''' + for generator in _GENERATOR_DB.keys(): + install_templates_translations(generator) + add_variables_to_context(generator) + interlink_static_files(generator) + interlink_removed_content(generator) + interlink_translated_content(generator) + + +def get_pelican_cls(settings): + '''Get the Pelican class requested in settings''' + cls = settings['PELICAN_CLASS'] + if isinstance(cls, six.string_types): + module, cls_name = cls.rsplit('.', 1) + module = __import__(module) + cls = getattr(module, cls_name) + return cls + + +def create_next_subsite(pelican_obj): + '''Create the next subsite using the lang-specific config + + If there are no more subsites in the generation queue, update all + the generators (interlink translations and removed content, add + variables and translations to template context). Otherwise get the + language and overrides for next the subsite in the queue and apply + overrides. Then generate the subsite using a PELICAN_CLASS + instance and its run method. Finally, restore the previous locale. + ''' + global _MAIN_SETTINGS + if len(_SUBSITE_QUEUE) == 0: + _LOGGER.debug( + 'i18n: Updating cross-site links and context of all generators.') + update_generators() + _MAIN_SETTINGS = None # to initialize next time + else: + with temporary_locale(): + settings = _MAIN_SETTINGS.copy() + lang, overrides = _SUBSITE_QUEUE.popitem() + settings.update(overrides) + settings = configure_settings(settings) # to set LOCALE, etc. + cls = get_pelican_cls(settings) + + new_pelican_obj = cls(settings) + _LOGGER.debug(("Generating i18n subsite for language '{}' " + "using class {}").format(lang, cls)) + new_pelican_obj.run() + + +# map: signal name -> function name +_SIGNAL_HANDLERS_DB = { + 'get_generators': initialize_plugin, + 'article_generator_pretaxonomy': filter_contents_translations, + 'page_generator_finalized': filter_contents_translations, + 'get_writer': create_next_subsite, + 'static_generator_finalized': save_main_static_files, + 'generator_init': save_generator, +} + + +def register(): + '''Register the plugin only if required signals are available''' + for sig_name in _SIGNAL_HANDLERS_DB.keys(): + if not hasattr(signals, sig_name): + _LOGGER.error(( + 'The i18n_subsites plugin requires the {} ' + 'signal available for sure in Pelican 3.4.0 and later, ' + 'plugin will not be used.').format(sig_name)) + return + + for sig_name, handler in _SIGNAL_HANDLERS_DB.items(): + sig = getattr(signals, sig_name) + sig.connect(handler) diff --git a/plugins/i18n_subsites/implementing_language_buttons.rst b/plugins/i18n_subsites/implementing_language_buttons.rst new file mode 100644 index 0000000..43f8bb3 --- /dev/null +++ b/plugins/i18n_subsites/implementing_language_buttons.rst @@ -0,0 +1,128 @@ +----------------------------- +Implementing language buttons +----------------------------- + +Each article with translations has translations links, but that's the +only way to switch between language subsites. + +For this reason it is convenient to add language buttons to the top +menu bar to make it simple to switch between the language subsites on +all pages. + +Example designs +--------------- + +Language buttons showing other available languages +.................................................. + +The ``extra_siteurls`` dictionary is a mapping of all other (not the +``DEFAULT_LANG`` of the current (sub-)site) languages to the +``SITEURL`` of the respective (sub-)sites + +.. code-block:: jinja + + +