ultralight-beam / ub.swift Goto Github PK
View Code? Open in Web Editor NEWSwift implementation of the ultralight beam protocol.
Home Page: https://swift.ultralightbeam.io
License: Apache License 2.0
Swift implementation of the ultralight beam protocol.
Home Page: https://swift.ultralightbeam.io
License: Apache License 2.0
Should run tests, lint.
Sometimes certain terms are annotated like this
or like this.
All terms are annotated in the same way.
Allow message passing over bluetooth
Think about a logging framework to use within UB. Provide proper logging for various layers.
Current candidates
Probably best to use either oslog
or oslog
through SwiftyBeaver
Services are a Relayer specific thing right now, this means that they can not be easily reused and added directly to a UB node.
There is message handling that is able to differentiate between a service specific and node specific messages, these messages are then handled accordingly. If they cannot be handled they are retransmitted.
We currently use proto
in the code base to describe ultralight beam services, this clashes with swifts protocol
type.
The proto
field is renamed to service
everywhere.
Get two or more devices to peer with one another over bluetooth.
Implement the Core Bluetooth library as a transport within the UB framework
Currently there is a transport.listen
function which takes in a callback, this does not seem like it fits into the rest of the design of Ultralight Beam which often uses delegates.
Look at trade offs of leaving it a callback vs a delegate function and consider changing it if need be.
We currently use the more high level bluetooth API. We should change this to the more low level L2CAP api. This will require writing generic streams that can be used by other transports too.
Implement a peer discovery mechanism, similar to flood sub.
Use github actions for both lint and test. Then we can remove travis and code climate.
Implement the MultipeerConnectivity library as a transport within the UB framework
The way MPC works, this transport will only work per app, and won't relay messages cross application by the looks of it.
Right now message routing is pretty random, or better said non-existant at all. We need a method which allows users to more effectively route messages within the networks themselves.
After reading the scribe paper (notes), I believe I have found a possible solution.
Ideally we can build a pubsub network over our transports using multicast trees similarly to how scribe does.
This means that a peer knows what topic they want to subscribe to, they find their surrounding peer with the closest address using some distance metric. Let's say for example:
distance(topic, node) = topic XOR node
Now what we do is on the closest node we register that we want to subscribe to a given topic. If that node is also subscribe it adds us to its list, if not, it recursively registers on the next node. Until a root is hit.
To make the trees fault tolerant, if a disconnect is detected, the node registers at the next closest.
The current Bluetooth implementation created with #52 is not power efficient as it continuously scans for peripherals to connect with.
Currently all nodes are also peered with, this should also be thought about.
The bluetooth transport features two running modes, one lightweight and one less lightweight. The former will be more energy conservative to run efficiently on resource restricted devices. This means it does not perpetually scan for peripherals and disconnects after sending messages. Depending on how much a node talks to a given peer connections are kept open.
we will need another package manager for mobile etc, eg cocoapods.
Create a gemfile to handle our ruby dependencies such as xcpretty and jazzy.
The node.send
function currently takes an argument of the type Message
this isn't optimal as we cannot expect endusers to know all those fields.
There are 3 functions, each for sending a message.
Sending to an address:
send(to: UBID, message: Data)
Sending to a service:
send(service: UBID, message: Data)
Sending to an address and service, this function is called by the above functions.
send(to: UBID, service: UBID, message: Data)
Create a github action that runs make docs
whenever a pull request is merged.
We currently have 2 methods of representing a message that gets sent around within UB. One is the Message
type and the other is the Packet
protocol buffer. The main differences are the fact that the Message
type is "more" type safe and has the last sender of a message.
We remove message from our codebase and pass around (last_sender, packet)
as a tuple where necessary. Functions that are responsible for sending a message take the input parameters as UB specific types and later cast them to those required for the protobuf internally.
Currently there is no proper message serialization.
Use protocol buffers to have a common message serialization across implementations.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.