Protobuf definitions for the Meshtastic project
Home Page: https://meshtastic.org
License: GNU General Public License v3.0
The Protobuf message definitions for the Meshtastic project (used by apps and the device firmware).
Noticed that in Waypoint and the Data messages emojis are represented using fixed 32 bit values:
protobufs/meshtastic/mesh.proto
Lines 778 to 781 in dea3a82
protobufs/meshtastic/mesh.proto
Lines 731 to 735 in dea3a82
Noticed in the Android app that for waypoints some emojis don't work, or show different icons. For example, the pirate flag emoji just shows as a black flag on the map.
Can't use the value in an enum in a picker
Add windspeed to Environment metrics to support serially connected weather stations and hopefully annenometers if we can find some suitable hardware.
Also remove the power fields from this message that were hacked on here.
Reduce uncertainty about device GPS config:
gps_accept_2d, gps_max_dop and likely more, assume sensible defaults.gps_operation field a boolean, rename gps_disabledlocation_share field a booleanESP32
Currently MQTT nodes lock-up with large node databases. Work around is to soft reset the node and quickly reset NodeDB.
Request to set a TTL on the NodeDB to about 60 minutes (RF and MQTT nodes). If nodes aren't heard within the 60 minutes - They're dropped from the DB.
https://github.com/meshtastic/protobufs/blob/master/meshtastic/channel.proto#L75-L84
There is no need to have uplink_enabled and downlink_enabled as part of ChannelSettings and ChannelSet since they don't need to be shared with all nodes in a local mesh to be able to communicate.
asking for consent to enter and to git
dragging and dropping container packages
usage/usages of
Hi,
This issue is part of a bigger functionality extension that should start with protocol buffers as an underlying implementation and later get propagated to actual firmware.
Created as a starting point for meshtastic/firmware#2150
Repurpose the existing environmental plugin to be a generic telemetry module.
The functionality should include:
AirTime, BatteryLevel, ChannelUtil and other high frequency data over the phone api, likely to be own message:message deviceMetric {
float channel_utilization = 1;
float air_util_tx = 2;
int32 battery_level = 3;
}position_flags field), another generic setting to determine the intervalThere are a few FIXMEs noting the fact that plugins currently configured in RadioConfig.UserPreferences should have their own section. Is this as simple as adding a RadioConfig.PluginPreferences and updating the plugin code in meshtastic-device? If so, I'm happy to submit a PR for it, I'm just wondering how often protobuf changes are propagated to the other projects.
In order to support dynamic heading from the compass to supplement/replace the derived heading from GPS, it would help to add a telemetry type for Compass sensors. These sensors all at least provide their raw 3-axis measurements. Some also will provide a derived 2d azimuth in the x/y plane that can be used after calibration directly.
Using all 4 canned message parts uses a ton of memory and slows down the device leading to a bad experience. One part stores enough messages for most uses and is a much better user experience
This is performing badly with multiple parts in 1.2 and 1.3 devices are doing quite a bit more.
To eliminate having a flat configuration structure, restructure the RadioConfig message as follows:
#before:
message RadioConfig {
UserPreferences preferences = 1;
}#after:
message RadioConfig {
oneof payloadVariant {
ModemConfig modem_config = 1;
GpsConfig gps_config = 2;
PowerConfig power_config = 3;
MQTTConfig mqtt_config = 3;
}
}Do people want to see Plugin(module) configuration appear at the same level as the rest of the config, or nested even further e.g:
#after:
message ModuleConfig {
oneof payloadVariant {
StoreForwardConfig store_forward_config = 1;
}
}
message RadioConfig {
oneof payloadVariant {
...
ModuleConfig module_config = 4
}
}As a mobile user; I want the position precision to decrease on ingress to a designated geolocation and increase to my general position precision setting on egress; so that I can increase geolocation obfuscation before I return to home or some other regular/sensitive location.
Other
T-Beam
1.3.0
Would the group consider adding Speed(MPH) and Heading (degrees) to the Existing GPS DATA to be consumed in the API for web/app etc...
this data is already in the existing NMEA data and used in "NMEA GNSS modules, https://github.com/meshtastic/Meshtastic-device/blob/master/src/gps/NMEAGPS.h"
using tinygps++ (the current GPS library) you call GPSobject.speed.mph() and GPSobject.heading()
No response
Allow the Neighbor message to store RSSI in addition to SNR.
Could you replace quote characters in two places in comments inside Mesh.proto. Windows cannot build protos project with following error:
main\java\com\geeksville\mesh\MeshProtos.java:11113: error: unmappable character (0x98) for encoding windows-1251
* then messages marked as reliable and finally �?background’ packets like periodic position updates.
and
* field in MeshPacket called �?priority’.
NRF52, ESP32
I propose a new role: Lost_and_Found. The idea behind this role is to address "SOS beacon" requests users have had, and to add new functionality not present in any of the current roles.
I also propose a new admin message that can change a device's role to this new lost_and_found one, so it can be done remotely via the mesh, to support one of two new use cases.
Use case 1: If a device is in Client mode, and either the person using it or the device itself is lost, remotely changing the device's role to Lost_and_Found will cause it to begin sending location packet updates at a configurable period of time (perhaps with a 1 minute default period) Either the device's onboard GPS module, the user's phone position data, or the last known position will be broadcast to the mesh with a canned message stating "I'm lost! Current pos: lat/long". This would satisfy users' request for an SOS feature, without necessarily characterizing it as a rescue feature but implementing a similar function.
Use case 1 modifier: Allow remote nodes, ideally only ones authorized to send admin messages, to change a remote device's role back to Client when the device in question is located, or to counter accidental or deliberate beacon spamming.
Use case 2: Same as use case 1, but the user manually changes their device role to Lost_and_Found. There should eventually be an easier way to do this besides changing the role in the current mobile app settings, such as a new app setting entry that has a single button labeled "Enable Lost & Found Beacon" that is not buried within app/device settings. It would ideally require user confirmation, perhaps even twice ("Are you really sure?") before activation to avoid accidental spamming of the mesh. Also some disclaimer that this does NOT alert search and rescue organizations, only other mesh devices would be necessary to avoid confusion.
Use case 3: Animal tracker, such as for a lost dog wearing a Meshtastic device with Tracker role configured. Same as use case 1 above, where the animal's owner would remotely set the device role to lost_and_found to help locate the lost animal.
Use case 1/2/3 enabler: Include a configurable Lost_and_Found role beacon period, with a reasonable default such as 1-3 minutes.
Use case 1/2/3 modifier: Include a setting for messages sent when there is no change in position for # (configurable) minutes; e.g. "(node name) No movement for # minutes", to advertise the node and/or user have not moved. Perhaps could rely on smart broadcast's movement distance threshold?
Currently we use both CamelCase and UPPER_SNAKE_CASE, camel seems to be the most widely used here.
Would like to try and not break the url format @andrekir also has thoughts.
Should we use a linter of sorts for our protobufs?
Super excited about the namespace change! One issue -- I'm not able to compile files with the new import style of import "meshtastic/FILE.proto". I'm pointing protoc towards the new protobufs/meshtastic directory, but it will only compile when I replace all import "meshtastic/FILE.proto" imports with import "FILE.proto". Not super familiar with protobuf compilation so very possible I'm doing something wrong.
Other
sx1262
https://github.com/paoloponzano/ponzy-meshtastic.git
Hi, i'd like to contribute to the firmware adding the needed changes to support a DIY variant based on a RP2040 board. I currently built one using a VCC-GND RP2040, eByte E22-900M30S radio module and common oled display. It has run without problems since last month and power consumption is great too. It could be interesting to those wanting to build a cheap node. Bluetooth support is ot of my skills for now
(photo: https://media.discordapp.net/attachments/919642584480112750/1215576756937822219/camphoto_824023566.jpg?ex=65fd4113&is=65eacc13&hm=782217e6a89a2caf07acfcda50664c0fdfc9bf37f57f4addfbea66fe6c8c19f2&=&format=webp&width=895&height=671)
This might be useful for who wants to use the ebyte module with other boards too.
Hi, I am writing a small " router " application for meshtastic mqtt messages. I need to extract the message ID from the raw message that the nodes send to the mqtt broker. However, I would like to not use the meshtastic library or any protobuff (I am writing my application in go)
There is some way to extract the message ID directly from the raw data without using protobuff libraries?
I tried to search on the docs but it appears that there isn’t any indication on how the data are encoded.
I also tried to look at some data with a hex editor and I wasn’t able to find the message id.
Can anyone help me?
Best regards, Lorenzo
All other oneOf's use the name payloadVariant this should do the same
ESP32
The "old" BMP180 sensors, which are way cheaper than the currently supported BMP280 and about 1/3 smaller, basically provide the same funcionality as the BMP280. AFAIK, the only significant difference is that the BMP180 only supports I2C, whereas the newer BMP280 also supports SPI (coming with a larger footprint).
The BMP180 is supported by the Adafruit Library for the BMP085, and i already did a first working implementation based on this library.
The changes would basically be an additional entry in TelemetrySensorType in the protobuf repository, and for the firmware the addition of the BMP085 library, a new class BMP085Sensor and some additions in the environmental telemetry code.
Generating admin.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
mesh.proto:8:1: Import "module_config.proto" was not found or had errors.
mesh.proto:83:5: "UNSET" is already defined in "Position".
mesh.proto:83:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within "Position", not just within "AltSource".
mesh.proto:88:5: "MANUAL" is already defined in "Position".
mesh.proto:88:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "MANUAL" must be unique within "Position", not just within "AltSource".
mesh.proto:93:5: "GPS_INTERNAL" is already defined in "Position".
mesh.proto:93:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_INTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:98:5: "GPS_EXTERNAL" is already defined in "Position".
mesh.proto:98:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_EXTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:218:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:218:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "HardwareModel".
mesh.proto:838:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:838:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "Constants".
mesh.proto:1234:5: "ModuleConfig" is not defined.
admin.proto:10:1: Import "mesh.proto" was not found or had errors.
admin.proto:11:1: Import "module_config.proto" was not found or had errors.
admin.proto:128:5: "User" is not defined.
admin.proto:148:5: "ModuleConfig" is not defined.
admin.proto:178:5: "User" is not defined.
admin.proto:197:5: "ModuleConfig" is not defined.
Generating apponly.proto...
Generating cannedmessages.proto...
Generating channel.proto...
Generating config.proto...
Generating device_metadata.proto...
Generating deviceonly.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
mesh.proto:8:1: Import "module_config.proto" was not found or had errors.
mesh.proto:83:5: "UNSET" is already defined in "Position".
mesh.proto:83:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within "Position", not just within "AltSource".
mesh.proto:88:5: "MANUAL" is already defined in "Position".
mesh.proto:88:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "MANUAL" must be unique within "Position", not just within "AltSource".
mesh.proto:93:5: "GPS_INTERNAL" is already defined in "Position".
mesh.proto:93:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_INTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:98:5: "GPS_EXTERNAL" is already defined in "Position".
mesh.proto:98:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_EXTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:218:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:218:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "HardwareModel".
mesh.proto:838:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:838:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "Constants".
mesh.proto:1234:5: "ModuleConfig" is not defined.
deviceonly.proto:8:1: Import "mesh.proto" was not found or had errors.
deviceonly.proto:24:3: "MyNodeInfo" is not defined.
deviceonly.proto:29:3: "User" is not defined.
deviceonly.proto:34:12: "NodeInfo" is not defined.
deviceonly.proto:39:12: "MeshPacket" is not defined.
deviceonly.proto:53:3: "MeshPacket" is not defined.
Generating localonly.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
localonly.proto:8:1: Import "module_config.proto" was not found or had errors.
localonly.proto:36:3: "Config.WiFiConfig" is not defined.
localonly.proto:65:3: "ModuleConfig.MQTTConfig" is not defined.
localonly.proto:70:3: "ModuleConfig.SerialConfig" is not defined.
localonly.proto:75:3: "ModuleConfig.ExternalNotificationConfig" is not defined.
localonly.proto:80:3: "ModuleConfig.StoreForwardConfig" is not defined.
localonly.proto:85:3: "ModuleConfig.RangeTestConfig" is not defined.
localonly.proto:90:3: "ModuleConfig.TelemetryConfig" is not defined.
localonly.proto:95:3: "ModuleConfig.CannedMessageConfig" is not defined.
Generating mesh.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
mesh.proto:8:1: Import "module_config.proto" was not found or had errors.
mesh.proto:83:5: "UNSET" is already defined in "Position".
mesh.proto:83:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within "Position", not just within "AltSource".
mesh.proto:88:5: "MANUAL" is already defined in "Position".
mesh.proto:88:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "MANUAL" must be unique within "Position", not just within "AltSource".
mesh.proto:93:5: "GPS_INTERNAL" is already defined in "Position".
mesh.proto:93:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_INTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:98:5: "GPS_EXTERNAL" is already defined in "Position".
mesh.proto:98:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_EXTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:218:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:218:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "HardwareModel".
mesh.proto:838:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:838:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "Constants".
mesh.proto:1234:5: "ModuleConfig" is not defined.
Generating module_config.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
Generating mqtt.proto...
module_config.proto:90:7: "DEFAULT" is already defined in "ModuleConfig.SerialConfig".
module_config.proto:90:7: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "DEFAULT" must be unique within "ModuleConfig.SerialConfig", not just within "Serial_Mode".
mesh.proto:8:1: Import "module_config.proto" was not found or had errors.
mesh.proto:83:5: "UNSET" is already defined in "Position".
mesh.proto:83:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within "Position", not just within "AltSource".
mesh.proto:88:5: "MANUAL" is already defined in "Position".
mesh.proto:88:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "MANUAL" must be unique within "Position", not just within "AltSource".
mesh.proto:93:5: "GPS_INTERNAL" is already defined in "Position".
mesh.proto:93:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_INTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:98:5: "GPS_EXTERNAL" is already defined in "Position".
mesh.proto:98:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "GPS_EXTERNAL" must be unique within "Position", not just within "AltSource".
mesh.proto:218:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:218:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "HardwareModel".
mesh.proto:838:3: "UNSET" is already defined in file "telemetry.proto".
mesh.proto:838:3: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it. Therefore, "UNSET" must be unique within the global scope, not just within "Constants".
mesh.proto:1234:5: "ModuleConfig" is not defined.
mqtt.proto:7:1: Import "mesh.proto" was not found or had errors.
mqtt.proto:19:3: "MeshPacket" is not defined.
Generating portnums.proto...
Generating remote_hardware.proto...
Generating storeforward.proto...
Generating telemetry.proto...
Done generating the swift files from the proto files.
Perhaps we should have a tagged, versioned release so dependent projects can use?
ESP32
On my Heltec wireless stick lite v3 I want to use. An 1.3 oled screen. Sadly it wil not work because in the build is screen=0
Would t be possible to change this, so an external screen can be used if wanted ?
Even better would be in the display options to be able to set if you want to use the screen on any device, with or without standard display mounted.
export BUF_TOKEN=***
buf push --tag latest --tag 516074f2e49743c234430abb2ea43ea3f66b0acb
shell: /usr/bin/bash -e {0}
Failure: cannot create tag "latest", a tag or draft with that name already exists
Error: Process completed with exit code 1.
All other modules follow the following naming convention name_module however the Serial module is labeled without the _ seperator i.e: serialmodule_enabled, Should be serial_module_enabled
Currently, all LoRa config is performed on the primary channel.
This should be handled along with the upcoming RadioConfig refactor.
ESP32
There is currently no region setting for Philippines (PH) using AS923-3 (915-918 Mhz, 25mW)
https://www.reddit.com/r/HeliumNetwork/comments/m8ljdd/anyone_running_a_hotspot_in_the_philippines/
The 434/868 Mhz frequencies are not free
https://lora-alliance.org/wp-content/uploads/2021/05/RP-2-1.0.3.pdf
Page 16 of 94
BLE/Wifi behavior for Tracker, Lost and Found, and Sensor roles is currently undocumented (missing from the comments).
The default password length for adafruit.io mqtt keys is 42 characters, so we probably need to increase the length of this field to 44-46 to support longer keys
Right now anyone who will find a node can bind their phone/other device to it and get access to the network.
It would be nice to add ability to completely turn off (and later optionally turn on) pairing of new devices to given nodes via admin channel commands.
Technically it will work through [Bluetooth enabled] parameter but that would work only for router-kind nodes. For end-user nodes usecase is - continue support of existing paired devices but don't allow new devices to join.
Another hacky way for screen-less devices is setting to random pin.
But again most convenient way would probably be - adding "bluetooth.mode" - "disabled". (while "bluetooth.enabled" - "true").
Also I suggest rename bluetooth.mode -> bluetooth.pairing_mode.
As we discussed @thebentern deprecate and remove any functionality in firmware using Attempt time and use the broadcast interval for everything sleep related.
I'm not sure if this has been reported before: None is a reserved word in Python and should never be used as an identifier for any programming element.
Changing None to NoError or similar should fix the problem, however since this may (likely) impact other parts of the code, a more cautious / phased approach may be required.
I had a channel mute (for os notifications) feature that was removed because of the transient nature of channel data, it was requested again and I would like to add it back meshtastic/Meshtastic-Apple#616 but I think I need a place to store the boolean on the device so it is retained when channel data is updated.
The BetaFPV Nano 900 Transmitter is compatible with Meshtastic but does not have an identifier in the protobufs, yet.
We are standardizing the Telemetry Environment sensors on I2C so we can stop posting nagging alerts about dangerous GPIO in the docs and make the user experience cleaner by autodetecting sensors.
NRF52, ESP32
The title largely describes it. Currently, "favorite" is an abstraction present in the iOS app. This helps keep frequent DM targets top of node list on the phome. If this were actually a NodeDB attribute (settable via CLI), then devices could be pre-provisioned for use by ad hoc groups with no user setup required beyond device pairing, wtih these "favorites" already noted for other devices in the group.
Per common practice
Years later there remains no way to delete the CSV file for range tests, create an admin messages so this file can be deleted.
Create a new enum field deviceRole to supersede is_router, is_low_power and likely more.
This will also allow for centralized configuration for the device's "purpose" and decrease influence of device's power state on usage.
This should also reduce edge cases by removing possible unwanted config combinations
In mesh.proto, there's a comment above modem_config:
/// Note: This is the 'old' mechanism for specifying channel parameters.
/// Either modem_config or bandwidth/spreading/coding will be specified - NOT
/// BOTH. As a heuristic: If bandwidth is specified, do not use modem_config.
/// Because protobufs take ZERO space when the value is zero this works out
/// nicely.
///
/// This value replaces bandwidth/spread_factor/coding_rate. If you'd like to
/// experiment with other options add them to MeshRadio.cpp in the device
/// code.
ModemConfig modem_config = 3;
The comment suggests to me that modem_config is the "old" mechanism, and that bandwidth/spread_factor/coding_rate is therefore the new mechanism. However, it says that this value replaces bandwidth/spread_factor/coding_rate.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.