srri-zz / openrelay Goto Github PK

This is currently not working. Make it work.

Docker https://www.docker.io/learn_more/ can be used to package apps and scale easily. Keep in mind to use that.

Keep OpenRelay’s menu bar open when normally browsing resources

Just putting my thoughts out there of broad picture what should we tackle first. We can then discuss which features amongst the first finalists should be tackled and so on. So, that we are doing the best in our abilities to bring the most important features out.

The list has been decided with the criteria like security and basic network functionality in mind as of now.

Node Availability:

• Throttling support (almost done)
• HTTP Proxy

Security:

• All the features present, in order
  • DDoS attack proofing
  • Athoritative node support
  • Hidden node support
  • Public Key replication
  • Encryption

Content Availability:

• All the features present, in order
  • ARP
  • Unperishable
  • Content Seeding

Usability:

• Can wait

Optimization:

• Can wait

Remove dependancy on external keyservers

I see the instances trying to access /proc/stat on my Mac OSX and failing IOError: [Errno 2] No such file or directory: '/proc/stat'

Please chime in if anyone else knows about it.

The package used for the API (http://django-rest-framework.org/) supports this, find out how it works and enabled it with sensible defaults expose it via new config option(s)

UnboundLocalError: local variable 'form' referenced before assignment

Just documenting this. Should be easy to fix.

Useful when using OpenRelay from across the network and not on the local computer where the gpg-agent can ask users for the key passphrase.

The <title> is empty on all the Open Relay pages.

This is a minor front-end task.

Using this as my base for documentation.

This shows up on my mac also now (which was working perfectly): -

Exception in thread Thread-97:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 483, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/AJ/work/projects/OpenRelay/lib/python2.7/site-packages/gnupg.py", line 536, in _read_response
    result.handle_status(keyword, value)
  File "/Users/AJ/work/projects/OpenRelay/lib/python2.7/site-packages/gnupg.py", line 446, in handle_status
    raise ValueError("Unknown status message: %r" % key)
ValueError: Unknown status message: u'ERROR'

Add the TOS to the Site.

AJ - "I realized that the IndexError happens everytime I upload a new set of file (to either of the running nodes). The reason being that the files fail to be signed."

Keep validated resources uncompressed in a volatile cache for faster serving

This task has one goal: Make the barrier to join OpenRelay lower

Task is multi-fold:

Documentation

Create neat documentation for this part (keys) of OpenRelay which is currently the toughest part to realize. If the bar is lowered here then a lot of interested folks can easily enter and install this software. This can include:

• What is this thing?
• Why does OpenRelay need this?
• Where to get it from for different OSs?
• How can it be installed?
• Where to get help?

Ease the debugging of this feature

• I think the current information Unable to sign file error is not sufficient. Still have to see what more can be given as an error/feedback to the user.

What do you all think about this? I know I have not touched OpenRelay in a while and this morning I got the same error as above which made me realize that if I, being a programmer [not matter how clumsy :)], cannot easily debug this thing then the bar should be lowered. [In fact, I have been thinking that usability must be improved in Open Source software altogether].

Please throw in your comments. I know that there are features we need to take care of at this point but if we can improve the usability side of this product, things are more likely to pick up. After a bunch of comments, I will start looking for how to approach this (of course, with your help - looking at you @rosarior :-))