Feedback wanted, making apps, suggesting ideas, etc


#1

We currently don’t have a process for accepting and broadcasting apps for Librarian. At the same time, I’m not quite sure if something like ‘app store’ is a good fit for Outernet (we broadcast all apps anyway so the receiver basically serves as an app store). Because of this, comments regarding the process of accepting apps for broadcast are very welcome.

Also, if you want to make an app, or have an idea for one, please post in this section, I’d love to hear about it.

To set the tone, here’s what I think apps are good for. The ‘content’ you see in Librarian are normal pages like Wikipedia articles and such. You can certainly shove an app in a piece of content, and it would work almost the same way as what we call ‘apps’. The key difference is that you have some code in a lightweight package with easy-to-understand metadata structure, and you have data that is broadcast separately, which the code uses to do its job. In future, apps will also have the ability to communicate with the server and perform SQL queries over its own SQLite database, etc, so the difference will become more obvious. Thus, apps are better-suited for people who want to publish courseware, weather, and similar interactive content. Programs like chat clients, and similar are currently not well-suited for apps that use Librarian API, because there is still no direct access to networking and no provisions for running code servers-side.

Another thing I want to hear is the kind of APIs you want to see on Librarian side. Currently, a lightweight jQuery plugin is provided that gives you access to a portion of the filesystem where pure-file broadcast is stored (the files you can normally see through the file browser). For instance, I think giving apps the ability to query the content library and contents of each content bundle (too much ‘content’ in this sentence!) would be very useful. Developers could come up with apps that provide a different way of viewing the content, for example.

Anyway, take a look at the example app I posted a while ago, and play with it a bit. If you need help setting up Librarian on your own PC to play with this feature, let me know. If you think it’s too difficult or something like that, please file a bug. We want to make it easy eventually.


#2

I think one way to deal with this is simply develop an interpreter(mark up language) within the Librarian and have a specific file type for ‘apps’. What would happen is the ‘app’ is simply code(mark up) that is broadcast and then when it is read by the Librarian(with the built-in interpreter) the app is simply constructed from there. Therefore, there isn’t really a lot of data to be dealt with since the Librarian does a majority of the work.

EDIT: I looked at the example given, and it is similar.

For the app acceptance process, I think a voting process similar to the regular Outernet voting process would be called for.

If an app is associated with content already being broadcast, there should be a smaller process of accepting it. A priority system could be used, but at this moment I don’t know what specifics should be applied for a priority system.


#3

Yeah, we’ll eventually need a voting system for apps as well, but also technical review by the community would be nice to have. We can’t review each and every app ourselves because that would slow things down to a crawl. Maybe something that would allow technical people to look at the code and flag it as safe, etc (e.g., doesn’t contain code that erases user’s content library, doesn’t interfere with other apps or Librarian itself). Of course, I don’t expect there to be that many apps in near future, so for now, the process is up for discussion.

Btw, if anyone wants to build an app for Outernet, let me know. We can arrange for it to be broadcast if it’s good and useful.


#4

I think it could be a similar process to how wikipedia deals with their articles. The idea would be that before an app is submitted, have a timer to have a time where other users can review the code themselves and maybe even change it up to make it better or more efficient, or find things that could cause problems. Then, when it is submitted a bot could remove potentially harmful code(have users report certain bugs that could cause problems, and then have the default pieces of code to detect for this).

Easier said than done.


#5

We can’t assume that the code is open-source, though. The safest assumption is that the original author is the only person that can fix the code, so problems with code should simply be reported to the author.


#6

That approach can be taken then. However, the concept can still apply.


#7

怎麼樣才能獲得