Proposing virtual nodes for people without websites
We had a discussion yesterday with a local community hub and during that time they made us realise that we are going to come across situations where an organisation doesn’t have a website to act as their node on the network but still wishes to use, say, the broadcast service. In theory, any static point on the Internet can become a form of node on the network, with limited functionality.
To tackle the problem, the idea proposed is that of a virtual node. simply put: we could create a thin layer that acts like a bunch of nodes on the network with a particular service but is an interface to specific functionality provided by social media accounts. It is a bit more complicated, as displaying the information has to adhere to the terms of service (if there are any) associated with the social media company.
It’s possible to be even more general and — given rules — could convert any form of structured text or web API into service information — so you could set it up enabling your freely hosted site to have some way of broadcasting information on the network, though in a limited capacity, through the virtual node.
Proposal Notice: this functionality isn’t yet available; it is an idea that we are going to work through in the future.Posted November 29, 2016 9:57 am by Charlie Fyvie-Gauld
SpringNet v0.3.0 Release – Protocol update and bug fixes
This slightly delayed 3-week-cycle release is pretty boring and brings in the protocol changes that enables multiple responses to be combined effectively into a stream of responses, with a ‘service/multi’ header and an End of Transmission response code to complete the stream. This is technically a cleaner approach compared to using delimiters as it locks the size of a chunk to a size instead of a special sequence of characters used to end a response, thus allowing any sequence of characters to be in the chunk without having to escape them. It also makes the stream data format agnostic. This protocol update makes breaking changes to previous version of the plugin.
Out with old prototype, in with the new specification
After a lot of contemplation on the design of the prototype’s network communication protocol — and a lot of needless hassle in continued development caused by it’s original design — it was decided to shift away from a binary protocol and embrace what most Internet services have been based on by providing a text based protocol. This is a good example of why prototypes are built — to see what works and what doesn’t. As the overall design progressed, it was becoming very clear that a binary protocol was the wrong direction and now it’s been rectified. While the network behaviour is the same, the mode of communication feels a lot cleaner and more natural.
Now we’re moving out of this prototyping stage and into a development that is much closer to the actual service. The node software has been cleaned up, tested extensively and now handles the new protocol. This also means the old specification has been scrapped and the new protocol specification working draft is being worked on and can be seen at our public repositories.Posted June 23, 2016 8:00 pm by Charlie Fyvie-Gauld