Chatting with:
Configure
Require strict STUN connection
This option can help ensure data sent between peers remains private by
disabling TURN fallback; however, you may be unable to connect to clients behind certain firewalls.
(Changes will only apply to new connections.)
Disallow map faults
When enabled, peers will react violently to non-destructive
map-package-errors, potentially increasing security, but at a great risk to connection integrity.
Render others' public aliases
Disabling this option will make all public aliases render as their
private-alias counterparts, or else not at all, moderately reducing the risk of exposure to crude
language. (This method is far from foolproof, and may be bypassed with little skill.)
Remember me
When enabled, your current public alias will be hard-cached in your
system, so you need not fill out the initial prompt every load.
Maximum ICE gathering latency
The maximum length of time, in milliseconds, to wait for local ICE
gathering before erroring. The higher the value, the greater the probability of a successful route, and
the more stable the network, but also the higher the ceiling on possible wait time.
Peer route timeout
How long, in milliseconds, to wait for a live peer to respond to a
route before auto-rejecting.
For a more comprehensive list of modifiable attributes, see defaultConfig in ./lib/index.js
About
Centrality, technology's greatest ally in the best of times, proves a grevious oversight in the worst. To give
an application a heart is to provide a single point of failure—a self-destruct button. One fatal stab to kill.
Not so with a decentralized membrane. Destroy ten interstices and fifteen more will fill their places.
No ammount of attrition can destroy the membranexus. This site is a simple demonstration of the larger Membrane, and as such is largely a toy, with little practical application.
This is a fundamental constraint of the implementation. Though chat is an easy use-case to demonstrate, it is hardly the best one for Membrane. I had initially dreamed of building a distributed cruncher for mersenne primes with it, a much better-suited use, but opted for chat due to its ability to use much of Membrane's full power, making it a more practical demonstration. With no central authentication server, spoofing and falsification are elementary. You must never trust anyone on this site. Membranexus.com is merely intended to demonstrate the great power of in-line distributed routing, and is hardly the most viable implementation of this framework. This said, by all means, please stick around and play with the webapp; I designed it to be as functional as possible for its purpose, and it is therefore a very much complete chat application.
This is a fundamental constraint of the implementation. Though chat is an easy use-case to demonstrate, it is hardly the best one for Membrane. I had initially dreamed of building a distributed cruncher for mersenne primes with it, a much better-suited use, but opted for chat due to its ability to use much of Membrane's full power, making it a more practical demonstration. With no central authentication server, spoofing and falsification are elementary. You must never trust anyone on this site. Membranexus.com is merely intended to demonstrate the great power of in-line distributed routing, and is hardly the most viable implementation of this framework. This said, by all means, please stick around and play with the webapp; I designed it to be as functional as possible for its purpose, and it is therefore a very much complete chat application.