To: AnonUser
Using streams or a general network or ipc based API may actually be the
preferable way to do things.

Sure, I would have to implement the basic programs first or port existing ones
(image viewer, video player, etc.), but it would allow the browser to be highly
extensible and offload security concerns from the base browser to the
individual programs which are also sandboxed per-process. It's basically the
OpenBSD way of doing security: keep the base so simple and generalized that you
can't have security issues. Everything extra beyond the base is a risk the user
has to willingly make.

How would it be if I would continue this idea to the extreme? For example, if I
were to generalize not only the network api between the browser and the
external embedded program, but also the way the browser embeds other programs
into itself, then I've essentially got a standardized file format where
everything is embedded. This would also mean that the screen space would be
divided up into blocks (think "html div" or "html block") in which the programs
would be embedded and this would also mean that even a "text block" would have
its own dedicated program which _only_ displays text.

I first thought about doing things the hybrid way with the previous embedded
idea where a text block is built in while something like an image or video uses
an external embedded program. The question is, why is a text block any more
special than an image? Why not go to the extreme and make it also an external
embedded program which displays text? The only advantage of the hybrid approach
is that it uses slightly less ram, but at the cost of extra complexity and
possibly security issues due to the added complexity (maintaining differing
ways to handle each block vs one truly generalized way).

I hope this incoherent rambling makes at least some sense :D. This may actually
be crazy enough to work well in practice...
--
Posted on RetroBBS

  To: AnonUser
As I mentioned elsewhere, using dedicated programs to the web would be
preferable for performance and efficiency reasons and there is a project that
does exactly that:

http://weboob.org/

It's written in python, but even so it's less bloated and more efficient than
the modern browser. I do not think it is _the_ way to solve the problem, but it
seems to be an interesting project nonetheless. One issue it has is that
content isn't interlinked as it is with the web, which is one major drawback.

This brings me to a similar idea that I'll try to formalize in another post.

- crowbar
--
Posted on RetroBBS

  To: AnonUser
Weboob.org got me thinking and I came up with an idea based on the principles
of Weboob.

With this idea, we will be dividing and limiting what "categories" of web pages
can exist. For each category of a web page we will have a dedicated program to
handle it. So it's basically like Weboob, where we have a few programs and
those interface to services.

We don't however write modules to support different websites in the sense
Weboob does, we create API's that dictate what is possible for each category
and for each category we create a dedicated program to handle it. Website
developers will have to implement those specific API's to allow the programs to
interface with them.

The problem of Weboob as I see it, is that between the programs there is no
linkability. If I am using the program which displays ASCII text, I want to be
able to click on a link inside it and let it open another ASCII text page. This
means that the programs themselves must be able to identify links on their own
_without_ extra metadata and have a mechanism to execute each other (through
the browser for example).

All these dedicated programs will then be tied together using a browser to
allow seamless tabbed usage of all programs like we have today on modern browsers.

The advantages using this approach:
* very easy to implement
* bloat-free
* anonymity and privacy is easy to guarantee
* controlled dynamic(!) content possible and also safe
* dedicated programs to handle each category
* easy to replace individual dedicated programs
* dedicated programs can be written in any language
* reduced bandwidth usage (markup not transferred)
* sandboxing individual programs possible

The disadvantages:
* less freedom for web developers, as they have to abide by category API and
don't have much room for customizations unless specifically allowed for by the API
* we _need_ to either heavily modify or write our own programs to make this work

I actually _really_ like this idea.

--
Posted on RetroBBS

AnonUser wrote:

  To: AnonUser
Weboob.org got me thinking and I came up with an idea based on the principles
of Weboob.

With this idea, we will be dividing and limiting what "categories" of web pages
can exist. For each category of a web page we will have a dedicated program to
handle it. So it's basically like Weboob, where we have a few programs and
those interface to services.

We don't however write modules to support different websites in the sense
Weboob does, we create API's that dictate what is possible for each category
and for each category we create a dedicated program to handle it. Website
developers will have to implement those specific API's to allow the programs to
interface with them.

This is an interesting idea. One thing the Freenet Project has done is provide
a simple interface to generate "Freesites". If you provide developers an easy
way to create their site, some might actually do so.

The disadvantages:
* less freedom for web developers, as they have to abide by category API and
don't have much room for customizations unless specifically allowed for by the API
* we _need_ to either heavily modify or write our own programs to make this work

I would assume only those who are interested in the project itself would create
sites, like i2p or Freenet developers write for their project out of interest
for the project itself. Others may not see any reason.

I actually _really_ like this idea.

It's very interesting!

--
Posted on Rocksolid Light

And once you are done, don't forget to include an api for federation to news servers. :-)

Posted on def4

  To: anon

And once you are done

That will take a while :). Still working out the specifications, but I have already started working on a prototype. I'll share my progress once I have it in a somewhat pre-aplha state.

don't forget to include an api for federation to news servers. :-)

Yeah, I'm planning to add federation support to the forum server when I get there. Rocksolid uses NNTP to federate, correct?
--
Posted on RetroBBS

  To: AnonUser
AnonUser wrote:

don't forget to include an api for federation to news servers. :-)

Yeah, I'm planning to add federation support to the forum server when I get there. Rocksolid uses NNTP to federate, correct?

That's correct, just standard nntp servers.

--
Posted on RetroBBS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have already started working on a prototype

I've called it "Lean".

Overall I'm not too pleased with it, but more on that later.

To give a quick overview, I've implemented:
- - A binary format specification called LDSF (Lean Data Serialization
Format) and implemented a library with property tests in Haskell
- - A protocol called Lean, a stateless binary protocol that uses the
binary format LDSF
- - A Haskell library called lean-client which is a simple to use client
implementation of the Lean protocol
- - A browser called Lean
- - A handler for the category "text" which gets embedded seamlessly into
the browser (ascii file viewer which highlights links such as
lean://example.i2p/text/some_text_file.txt and makes them clickable)

One thing I'm really not happy about is the delay introduced by launching
the handler programs. e.g. when you browse to
"lean://crowbar.i2p/text/test.txt", it knows it has to launch the program
lean-handler-text because of the /text/ in the URL to handle it, but the
delay of starting a GUI program is not insignificant and therefore quite
noticeable.

This delay is especially prominent on single board computers, _even_ if
the handler program is written in _plain old C_. A GTK+ or Qt GUI program
simply takes a bit to start up and there isn't much one can do other than
pre-launch that program and let it idle around. It currently uses around
3-4MB private memory for the browser and around the same amount per
handler. So the RAM usage per tab would be around 3-10MB depending on the
content and handler.

Right now, because I haven't implemented a "real" server yet, the browser
just acts as if it would be corresponding with a server. This is so that I
can test the interactions between the browser and the handlers, which is
the most important bit right now.

I did not expect embedding would be such a pain in the ass and quite
messy. Getting it working reliably on multiple window managers on Linux is
probably going to be a real nightmare.

I've attached the source code.

SHA512:
2bb31805e9433ccf9d58fc389f1367560c0c3bd6c80e80ef642531274c4bfbb51be0efbb7021be38a82d12945fd6931db970e804e582c5b29b543c7a6faea073

There's a a README.md file in there that explains how to build it.
Currently it only works on GNU/Linux with X11. It's only a prototype,
don't expect things to actually work properly. No idea if I'm going to
continue with this.

Quickstart:
cabal new-build lean lean-handler text
cabal new-run lean
then type into the url bar: lean://crowbar.i2p/text/test.txt
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpEYKneGsL7jdIXI0J9v/HQMk01EFAl3my7oACgkQJ9v/HQMk
01H1tg/7BzH4hAJn80t7Zhxe53kTHd0Te8lAIhBCbR2W4sKpjsf2C86ArgkCB08A
4PmfFSOJtfyA1PF8/WEXEfWh8ZVMTTVuv/tOd6P7jr6+H1dAGuDwS/rJPJrgB1Vx
dliWUlCAyfp3Yr0EfNXLLb0YWTw5bCuAEVneP4HtezXBhv8zJWYbTs65sAMtEQXo
E722GKzmuSvhtDJDl64YIpH6RTX6fAhiwFQB5c6bNuPOjX/mpsCoM7A7zMH6w505
t8hGEMADP3pvucsa0NAR9XguglwD0dhaA7L05DjFdxuRmqljB8n2NkIaYFDv3JhP
AenxS4loVpiFceMAOneSrRdwHxSIw/bWnBi5QCqLJQ0wAwbqdHLqXTHYlJXA6MXi
db9eJUiZ+YmtPuFyTpVUfhOZmafpn10MQuDE05F3EctyRPKWDGjrnDw0FRsNCd73
25jionto1fnbyoQ2MIgoWA56g4ZC6irnlgC5ykQCIgTiNvztInraB16wxtrRsbNb
iNTlEnP1jEqmbrdBftk5DX6BqlXac/gVuKmEkCb+w2TehZsv6m9SvBqC2s+BJ9yu
Uxie4a2B+sGd11fX9ea9J49eyqWVxjRxoj3gDQ1I6viPbk+yEIMZobwOmZ04Lta/
Tix/sKSn8Pl2QQuq8BiJYY1VzSkSCjIlF3yGHn52TKV5hJlNqIs=
=J/yA
-----END PGP SIGNATURE-----

--
Posted on RetroBBS



Attachments: lean.zip (application/zip)

thats some cool shit, my dude. i thought you would spent more time on the specs.
concerning the loading: you could try to select (and recommend to your users) a set of programs which are very lightweight and quick. Could be something ncursed based for the text part, for example. and those who prefer to use bloatware hopefully have the machines and the ram for it.
sounds really like a nice start anyway. Posted on def4

  To: anon

thats some cool shit, my dude. i thought you would spent more time on the specs.

Thanks. Specs are far from complete, ultimately I want to specify everything, remove all ambiguity and write them in RFC-format. This is mainly to see if it is any good in practice.

concerning the loading: you could try to select (and recommend to your users) a set of programs which are very lightweight and quick. Could be something ncursed based for the text part, for example. and those who prefer to use bloatware hopefully have the machines and the ram for it.

This is a good point, ncurses based UI would be extremely fast and also very usable with this design. I still want to make a GUI version that is extremely fast on single board computers if possible. I have a few ideas I will be testing.
--
Posted on RetroBBS

If you want a starting point for PDF specification, look at PDF/A. It's the archival format that already has most of the bloat removed. The problem with PDF is these different variants all fall under the .pdf umbrella and are not visually differentiable based on suffix, which is important in this situation.

--
Posted on Rocksolid Light

The Gemini protocol seems like a better fit for this. It is plain text and therefore directly readable in its' original state, and it can be rendered in its own graphical browser, like Lagrange. It should listen to mime types and therefore launch image viewers and audio players externally if they are not incorporated in the gemini client itself.

The protocol is trivial to implement and could be made to function over I2P and/or tor without much problem. There are already dozens of clients and servers for it, for I2P one could utilize SAM to make a client and server for instance.

--
Posted on Rocksolid Light