Difference between revisions of "Red Matrix"

From Organic Design wiki
m (Path bug)
(Change source-code blocks to standard format)
Line 11: Line 11:
 
== Our installation ==
 
== Our installation ==
 
We have a test installation running at [http://red.organicdesign.co.nz red.organicdesign.co.nz]. The installation process was a simple standard LAMP application installation, just ''git clone'' the code-base and add a few rewrite rules as follows - they recommmend using their ''.htaccess'', but we have this functionality disbaled and added the following rules to our global Apache configuration instead.
 
We have a test installation running at [http://red.organicdesign.co.nz red.organicdesign.co.nz]. The installation process was a simple standard LAMP application installation, just ''git clone'' the code-base and add a few rewrite rules as follows - they recommmend using their ''.htaccess'', but we have this functionality disbaled and added the following rules to our global Apache configuration instead.
{{code|<pre>
+
<source>
 
RewriteCond %{HTTP_HOST} ^red\.
 
RewriteCond %{HTTP_HOST} ^red\.
 
RewriteCond /var/www/domains/red%{REQUEST_FILENAME} !-f
 
RewriteCond /var/www/domains/red%{REQUEST_FILENAME} !-f
Line 18: Line 18:
 
RewriteCond %{HTTP_HOST} ^red\.
 
RewriteCond %{HTTP_HOST} ^red\.
 
RewriteRule (.*) /red/$1 [L]
 
RewriteRule (.*) /red/$1 [L]
</pre>}}
+
</source>
 
When I first installed it, the installer pointed out a number of environment options that needed fixing which was quite straight forward, but for some reason the application wouldn't run so I left it for a couple of months and then did a ''git pull'' to update the code-base and tried again. Something must have been fixed, because now our test installation is up and running :-)
 
When I first installed it, the installer pointed out a number of environment options that needed fixing which was quite straight forward, but for some reason the application wouldn't run so I left it for a couple of months and then did a ''git pull'' to update the code-base and tried again. Something must have been fixed, because now our test installation is up and running :-)
  

Revision as of 18:11, 22 May 2015

Red is kind of like a decentralised social network (along the lines of identi.ca, Friendica, and Diaspora), but they've thrown away the rule book. Red has no concept of "people" or "friends" or "social". Red is a means of creating channels which can communicate with each other and to allow other channels permission to do things (or not). These channels can look like people and they can look like friends and they can be social.

They can also look like a great many other things - forums, groups, clubs, online websites, photo archives and blogs, wikis, corporate and small business websites, etc. They are just channels - with permissions that extend far beyond a single website. You can make them into whatever you wish them to be. You can associate web resources and files to these channels or stick with basic communications. There are no inherent limits. There is no central authority telling you what you can and cannot do. Any filtering that happens is by your choice. Any setting of permissions is your choice and yours alone.

You aren't tied to a single hub/website. If your own site gets shut down due to hardware or management issues or political pressure, the communication layer allows you to pop up anywhere on the Internet and resume communicating with your friends, by inserting a thumb drive containing your vital identity details or importing your account from another server.

Your resources can be access controlled to allow or deny any person or group you wish - and these permissions work across the Red network no matter what provider hosts the actual content. Red "magic-auth" allows anybody from any Red site to be identified before allowing them to see your private photos, files, web-pages, profiles, conversations, whatever. To do this, you only login once to your own home hub. Everything else is, well - magic.

Red is free and open source and provided by volunteers who believe in freedom and despise corporations which think that privacy extortion is a business model. The name is derived from Spanish "la red" - e.g. "the network".

Our installation

We have a test installation running at red.organicdesign.co.nz. The installation process was a simple standard LAMP application installation, just git clone the code-base and add a few rewrite rules as follows - they recommmend using their .htaccess, but we have this functionality disbaled and added the following rules to our global Apache configuration instead.

RewriteCond %{HTTP_HOST} ^red\.
RewriteCond /var/www/domains/red%{REQUEST_FILENAME} !-f
RewriteCond /var/www/domains/red%{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /red/index.php?q=$1 [E=REMOTE_USER:%{HTTP:Authorization},L,QSA]
RewriteCond %{HTTP_HOST} ^red\.
RewriteRule (.*) /red/$1 [L]

When I first installed it, the installer pointed out a number of environment options that needed fixing which was quite straight forward, but for some reason the application wouldn't run so I left it for a couple of months and then did a git pull to update the code-base and tried again. Something must have been fixed, because now our test installation is up and running :-)

Path bug

For some reason our installation had a problem whereby any pages in sub-categories such as /profile/foo or help/intro wouldn't load their CSS or JS as the base-url setting would become a sub-directory instead of the root of the domain. I isolated this to the setting of $path on line 634 of boot.php which was basing its value on $_SERVER['SCRIPT_NAME'] to test if the installation was running in a sub-directory. I think perhaps it should be testing $_SERVER['SCRIPT_FILENAME'] instead but I'm not sure. I've contacted the lead developer with this info and just forced $path to an empty string for our installation since we're not in a sub-directory.

Articles about Red

See also