Conversation
|
How would it be done if you wanted to keep the data private? Guarantee the use of a private relay? Would you use encrypted data? Would you use private messages within nostr? It would work very well for a public knowledge network of climate information, for example. |
|
What if the data from sensor has different unit specified in nip |
|
Matter looks like a decent evolving standard, which already tackled quite a lot of different device types. IMO it would make more sense to have a Matter over Nostr type of bridging? |
|
Now we wait for the first implementer. :) |
|
Home assistant does a pretty good job at defining entities and data types for a home and probably commercial application. Industrial applications would require a different set of entities/data types. https://developers.home-assistant.io/docs/core/entity/ |
|
What is Matter? Can you drop a link? @mutatrum |
For now, yes. We don't have to solve all the things at once. |
You perform conversion, should be a simple formula in most cases -- or we make a new kind for data in a different unit if that is impossible. But maximum interoperability requires everybody publishing data in the same unit -- someone will have to perform conversion somewhere. |
| } | ||
| ``` | ||
|
|
||
| Ideally each device would have its own public key, which allows for easy command-and-control and comes with built-in trus guarantees (i.e. you know you're getting the data from the correct device if you know its key and can check the signature), but the `device` tag exists for when that is too cumbersome and more than one device is using the same key. |
There was a problem hiding this comment.
What I meant was that you can know for sure who is publishing the data given the signature, but it's definitely confusing. Please reword.
There was a problem hiding this comment.
What I meant was that you can know for sure who is publishing the data given the signature, but it's definitely confusing. Please reword.
I got it and the previous comment is about typo haha.
suggestions:
"and ensures data authenticity with build-in properties. "
There was a problem hiding this comment.
Sorry, sir, I'm not an English speaker (and I still don't see the typo).
There was a problem hiding this comment.
"built-in trus guarantees" is missing a t in trust.
fiatjaf
changed the title
Shouldn't the events be replaceable? So maybe use 18000-18999 range instead. The subscriber keeps the history if it wants. |
That's my point. For typical IoT data, there is no reason for the vast majority of the data to be stored. That's one reason that MQTT servers don't store data, only state, but MQTT clients devices and services might. Typically the client connections are also treated as ephemeral with a timeout setting to forget the device should it not connect for a certain amount of time. It could be minutes, it could be months... The ability to ascertain if the last known state is valid, or simply the last time that a device was online begins to be a functional requirement as the requirements of trust go up. They have solved this in some ways with the Sparkplug B Specification for devices and MQTT servers. That's all I"m saying. I'm not intending to ruin the fun. There is the other issue of the sheer number possible combinations of devices, entities, data types and attributes that will far outnumber 1000. Trying to hard code this is not feasible. I've worked on a couple of projects where we had to solve this problem. That's another conversation. |
|
Caveat: I haven't read the actual Matter protocol specs, but what I do know
is they have the device topology worked out. It's a transport layer
agnostic system, so on the surface it would look like an easy step to
mangle this onto Nostr.
https://csa-iot.org/all-solutions/matter/
|
I've tried to read the standard, but it seems that CSA is acting as a gatekeeper for such information. I've heard the promise for a while, but I'm still waiting. Not surprising. Over my career there has been a repeating cycle of some company or organization promising to bring order to the chaos and then becoming compromised by big money board members or combative participants that don't agree with the standard. My personal favorite is relaxing the standard so that a company may show the badge of conforming to the standard, but you need to use that specific company's software/gateway/client to get all the useful features that are not part of the standard, but easily could be... Call me jaded. A simple [Device]/[Attributes]/[Properties]/[value] arrangement is usually all that's needed. I do hope that they are completely open and successful. The next question would be if their definitions also apply for commercial and industrial IoT models and devices. I don't really care who knows the temperature of my refrigerator, but there could be some interesting use cases in the industrial market for interacting with remote sites where key signing could be used to authenticate a command from a remote operator. |
|
Adding nostr implementation to https://tasmota.github.io would be very cool. |
|
I was pushing weather station data to kind 1008, moved script to 8003 for now, would be nice if you can push multiple k/v pairs in tags otherwise i would have to push multiple events. You can find the data on data from stations: {
"time": "2023-10-15 22:42:37",
"model": "Fineoffset-WHx080",
"subtype": 0,
"id": 196,
"battery_ok": 1,
"temperature_C": 4.2,
"humidity": 90,
"wind_dir_deg": 45,
"wind_avg_km_h": 0,
"wind_max_km_h": 0,
"rain_mm": 658.80005,
"mic": "CRC"
}
|
|
Could I create a private chat with all the keys for my IOT devices and control and configure them via NOSTR? This way you would be able to use a public relay but keep the data and communication private. Is this approach possible? What would the event types look like in private chats? |
This is the entire point of the original IoT NIP #814 NIP91 is confusing sensors as IoT devices. A sensor sends data to something that connects to the internet, which is why its an Internet of Things. Any device that can connect to the internet can also encrypt data, even the IoT lightbulbs in my house. What makes nostr IoT special is the very fact I can communicate with devices in my home without having to invite the state and corporations in. Sure you can do sending of data over clearnet, such as weather stations and the like, but its really not that interesting. Devices could just send data to some server. A future of IoT with control over our personal networks through tcs, is a serious threat to liberty of humanity. Nostr can and should fix! ALL the IoT devices in my house would be able to connect to a nostr relay and ALL would be able to do encryption. |
But with MQTT this has been done for some time. What does NOSTR add in addition to what MQTT already does? Having MQTT and having a private nostr relay is not the same thing. The only advantage I see in using NOSTR for private data is not needing to have a server at home and being able to use the NOSTR network securely. |
|
Im not advocating a private nostr relay. Your 2nd point applies to everything that has been built for social networks on nostr Im saying this nip (91) is fairly redundant, just send data to some open-weather service. It certainly doesn't interest me. Keeping the state and corps out of personal network does interest me. Did you read the original nip #814 (107)?
What you said is the whole point of #814 |
|
@arcbtc You can just GiftWrap the event for the private use case: #716 You don't need the Seal+Rumor solution if you don't want to block the receiver from rebroadcasting the event and breaking privacy. Thus, just create a public 8003 kind as usual and then GiftWrap it on a 1059 kind to make it private In that way, people watching your relays won't even know you are transferring IoT packages and you help increase the anonymity set of your actual DMs, once DMs get GiftWrapped as well. |
|
#814 is not reliant on running relays, you can use public relays. Sure, event can be clearnet or NIP04 (or whatever comes next when its ready). NIP91 has been created for sensor data only, wholly underestimating the power of pretty much all IoT devices, as if the sensors themselves are the IoT device, which doesn't exist. Even for the dumbest IoT devices its a sensor connected to a micro-controller, that can do everything needed to create a proper event/DM (as outlined in #814) |
|
GiftWraps are also not reliant on running relays. That was the point of making them: To privately transfer any sensitive Nostr event through public relays. |
|
When its ready for DMs LFG! |
|
I think the most interesting part of this is standardizing public data broadcasts and using the native Nostr authentication properties to control things that are at least partly public. If the goal is to send private messages then I don't think we need a NIP, you can just use whatever is the standard for private messages but make devices chat between them using some proprietary messaging mechanism. Or the need for a NIP must be justified better with more concrete use cases. |
|
I just think it should not be placed inside a |
|
Wouldn't it make sense to have an update on kind 4 with a tag indicating what the content is from another kind? This way, customers would be able to filter easily and it would be a comprehensive solution for all other possible types. |
Well, if we care about backward compatibility, that would still break all DM clients out there that will just be showing JSON bare files in the DM screen. A new kind can be just like kind 4 if people want. It just doesn't break existing user interfaces. |
|
Why would a normal person try to DM an IoT device and vice-versa? If they want, shouldn't they be allowed to? |
|
One simple example would be to change the temperature setpoint of your
thermostat to make your home warmer before you get there. A similar example
in the commercial world might be to remotely allow access to a building, or
set lighting levels in a space. In the industrial world it is less common
to allow remote control of systems, but rather use for remote monitoring.
Safety being the largest reason behind this. The counter to that general
rule are systems that by nature are remotely operated. Again, the most
common interaction would be changing setpoints for temperature, speed,
pressure, etc. of the equipment. IoT devices publishing data from a remote
system or site for storing in a database for monitoring, alerting, alarming
and reporting will typically be 100,000:1 compared with publishing TO a
remote device to change settings, etc. and this is true in residential,
commercial, and industrial markets. At scale we expect many gigabytes of
data (Sometimes 60+Gb) from a small industrial remote site to flow through
an MQTT server each month. It feels to me that there is a general
misunderstanding of what IoT/IIoT means/is, the capabilities of existing
solutions (including FOSS and open source), and where nostr would be a good
fit/addition to the existing technology stacks in residential, commercial,
and industrial systems.
…On Mon, Oct 16, 2023 at 9:49 PM fiatjaf_ ***@***.***> wrote:
Why would a normal person try to message an IoT device and vice-versa?
—
Reply to this email directly, view it on GitHub
<#817 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALUGNPB76KELUSIEGFF6J3X7XP3PAVCNFSM6AAAAAA54A7WT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGUZDONBQGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
it doesnt have to be DM right? |
What I mentioned was that to not have to have a private relay, I could use a public relay and create a private chat between all my device accounts. So the end, which is the user interface, can receive all messages securely without having to expose data to everyone. Which I think is more complex than using MQTT, which is why I don't see much use in NOSTR for IOT in private data which is the majority of its use. |
|
If the content of the event is encrypted then:
Disadvantages:
|
|
The whole purpose of IoT over Nostr is to circumvent Orwellian TCs in IoT software and hardware, which is achieved by encryption (something all IoT devices can do). Thats what is outlined in the original proposal #814, and that is what nostr IoT SHOULD be. Not this strange lorawan over websockets affair This NiP (91), is VERY confused, treating nostr like lorawan, sending instructions as event kinds, even though the device will be communicating over websockets NOT lorawan, AND most communication will be to non-generic devices. ie my solar batteries battery manage system, sending array of non-generic sensor data and I will send an array of instructions back. |
Nonesense, that data structure should be the same. Something simple like a light would share clear obvious commands on/off, timer etc. there will be some generic commands. Most IoT devices will not have generic commands and sensor data, which invalidates NIP91 entire event kind proposal. We are talking Internet of Things, all the things, not just a wind sensor sending data over lorawan. It must be encrypted and generic enough for many devices, but also have "some" shared data types. Like #814 IoT devices are just clients and clients who need privacy to communicate between themselves or with users. All are just clients, with tha right to privacy. Privacy is what makes nostr IoT great. |
We just need a flag (not social media). NIP04 is used in nostr market as well. NIP04 is just encrypted data, social media doesn't have the monopoly on that |
My issue is that there is no standard. Therefore, each entity dictates the format that interests it and therefore it is not possible to easily integrate several devices. |
|
Which is why there are common tag types in #814 |
|
Can we leave this NIP proposal open for public IoT data -- private IoT data goes in the discussion on the other NIP, how about that? |
|
I would strongly suggest separating device status updates and IoT data streams from an RPC interface with the IoT device. It doesn't make any sense to use the same kinds for both use cases. |
|
Note:
|
|
All event kinds can be DMs. Just encrypt and p-tag the receiver. There is no reason to force the use the text DM for RPC calls. This is why almost no one implements NIP-15, but most clients implement NIP-47, which is a similar RPC strategy. |
Clarifications:
|
Yes. And yet, no one is doing that. In fact, NIP-47, NIP-46, and DVMs are all older than NIP-15 and their authors went to the trouble of creating brand new NIPs to avoid using NIP-15's scheme. That should tell you how much people dislike the approach. The only way to use a Create separate kinds for separate payloads. Then clients can decide to support the kind and appropriately render it or not. |
|
I think this discussion is derailing a little bit, my comments:
I think I see where the confusion lies:
|
Yes, this is why this PR exists: To define event kinds and payloads away from But you are failing to see the reason. Clients choose which types to support. A decision to support human DMs should not mean that you have to parse all the stuff that comes from IoT devices and vice versa. There is no point in mixing the two (human and machine code). Both sides lose when it happens. A client that supports Clients can then choose to support only Temperature sensors and nothing else. It makes everybody's life easier. |
|
Show me where it is specified (implicit or explicit) that NIP04 MUST be "human readable". That is just a |
|
|
|
OK, enough of this. Some serious questions which in my opinion are blockers. To all participants in this thread:
Questions:
My answers:
|
It's fine to take just one of these use cases to make a NIP for your needs. Just be aware that others will definitely exist. |
|
There are chats where the same message is encrypted to each receiver, which works well for small groups, and there are NIPs for large groups. Those require a shared secret of some sort.
Yep, I don't see it as well. I am close to two kinds of IoT:
There will be public sensors: weather stations, crowd-control systems, traffic counting devices, etc. Those are all public. Then there is the smart home stuff, whose control (write access) is generally shared between 2-3 accounts. GiftWrapping those should be fine as well. |
|
@motorina0 I think these questions make no sense because there are two completely different use cases at play here. One is a kind of RPC interface between private devices. These can use a single encrypted event kind for these devices to talk between each other, and we can maybe standardize some kind of JSON-RPC interface between them. The other -- which this PR is about -- is just public data being broadcasted to the world for everyone to see, so no encryption ever at all. |
11 participants
Full text: https://github.com/nostr-protocol/nips/blob/iot/91.md
This is based on #814 (comment).