Allow me to digress from the usual topic on this channel once more.
I'm pretty sure that no human being on this planet has created nearly as many federated social platforms as @mike. But all these (actually not always so) different platforms can be a bit confusing. Even I may be wrong here and there, but I'll try to make some sense of them by putting them into a kind of chronology.
So first, there was #Friendica. Only that it started out under the name of #Mistpark. I'll get to the name later.
Remember #Diaspora? Remember summer 2010 when the crowdfunding run was launched so that those four guys could spend all their time creating a free, #OpenSource, decentralised, federated social network (a.k.a. #Facebook killer) which they wanted to name Diaspora*?
Well, they unknowingly wanted to re-invent the wheel. #StatusNet was already there, #GNUsocial was already there, and especially, Mistpark was already there with a 1.x release and more powerful than both, actually, more powerful than Diaspora would ever become. I think Mistpark even already had Diaspora*'s aspects, only that they were called groups.
As for its concept, Mistpark went beyond that of Diaspora*. Mistpark didn't only want a bunch of instances ("nodes" in this case) of its own kind to connect with one another, it also wanted to federate with everything else that moved, be it e-mail, be it StatusNet, be it Twitter, be it whatever.
The first name change was from Mistpark to #Friendika. The reason was that the original name sounded repelling to German speakers. "Mist" means "fog" in English, but "dung" or "manure" in German, not to mention that it's a German curse word.
When Diaspora* was finally there, Friendika didn't see it as competition, it saw it as another federation target. To this day, Friendica is fully federated with Diaspora*, and that has exclusively been the work of the Friendika developers who studied Diaspora*'s source code and reverse-engineer it because it didn't have an API.
Probably the biggest coup was the bidirectional federation with Facebook. This was what everyone was waiting for. This, however, was also where the trouble started. Facebook didn't want to be federated with a non-commercial social network and started taking defensive measures. Also, Friendica users (the second name change was through meanwhile) who used the Facebook connector had their entire and often very busy Facebook timelines mirrored onto Friendica nodes, one of the reasons why even nodes on powerful root servers often had to close new registrations even though they only had a little over a hundred users. So there were several reasons why Facebook federation was axed again.
Internally, Friendica uses its own protocol named #DFRN. But I guess Mike had meanwhile seen it as a dead end, also because he had a new idea: #NomadicIdentity, not only the ability to easily take your account from one instance to another, but the possibility to have it on multiple instances at the same time, keeping the copies in sync.
That's why he laid the foundation for a new protocol that could do that: #Zot.
And with it came the next social platform. It was first just simply named Red from Spanish "red" = "net". Red was based on Zot from the beginning, and as an experimental platform, it only understood Zot. On Friendica which was now running at full steam on dozens upon dozens of nodes, and which Mike had passed on to the community, the development was followed with interest. And just like later platforms, I think Red actually got a few small public instances because someone really wanted to try it out. Red eventually changed its name to #RedMatrix.
Also, Red didn't just want to be a social network like Friendica. The idea was rather to have a "social content management system" that could do just about everything you could do with a website and/or a cloud server. Third-party federation was slightly reduced, connections to commercial platforms didn't come back. But as Red evolved, the Diaspora* connector was included which was also used to federate Red with Friendica.
From the Red Matrix emerged #Hubzilla, the Swiss Army knife of the #Fediverse. Still today, its possibilities have rarely ever been fleshed out: not only microblogging, but macroblogging, article publication, websites, wikis (no, I'm not kidding), #WebDAV, #CalDAV and #CardDAV server and so forth.
Next to the nomadic identity that came with Zot, Hubzilla introduced another killer feature: one account, many separate channels. Each one of these channels is basically like one Friendica account. You can have multiple fully separate identities on one account, and nobody (except the instance admin) can tell that they're all you. So this goes way beyond Friendica's multiple profiles. By the way, Hubzilla still has multiple profiles per channel.
Some say that the Red Matrix was renamed Hubzilla. This isn't true. Hubzilla is a fork of the Red Matrix, one could say it was a stable snapshot of the Red Matrix.
For the development of the Red Matrix continued. Planned advancements on Zot couldn't be tested on stable Hubzilla, they needed their own testbed. Eventually, the last Red Matrix instance was Mike's personal one with himself as the only user. It still federated with Friendica and, of course, Hubzilla.
In the meantime, #ActivityPub came along. It wasn't just another obscure networking protocol, though, because #Mastodon made it huge. So at least Friendica and Hubzilla had to adopt it. Friendica firmly integrated it. Hubzilla made it into an app just like all other protocols that aren't Zot because they stand in the way of fully nomadic identity. By the way, both profited from its introduction because the federation between each other no longer had to use the Diaspora* protocol.
For the next advancements of Zot, two new platforms were forked from the Red Matrix or Hubzilla. At this point, Mike wasn't involved with Hubzilla anymore either. First, there was #Osada, an early testbed for what would become #Zot6, but still with ActivityPub. For pure Zot6, #Zap followed suit. Most connectors that are neither Zot nor ActivityPub, including the one to Diaspora*, weren't taken over, as were many of Hubzilla's extra abilities (websites, articles, wiki, CardDAV, two parallel calendar systems etc.) to keep it slim. It did get to keep the various types of channels as well as one CalDAV server and the WebDAV connection, though.
Eventually, when Mike handed them over to the community, they used the exact same code base. The only differences between Osada and Zap was whether or not the admin had ActivityPub on (Osada) or off (Zap) and the name.
As having two different names for the same thing, depending on the instance configuration, Osada was discontinued in favour of Zap which now included ActivityPub itself. In the meantime, Zot6 became stable and was backported into Hubzilla which thereby became fully compatible to Zap, only that what Hubzilla can that Zap can't cannot be mirrored to Zap.
Then Osada re-emerged as Zap's unstable branch. Along with it came a new Red Matrix which, as far as I could see, was now an even more purist, even more unstable branch that only served for testing Zot8 and lacked all other protocols.
To top this off, in 2020, Zap itself got a stable branch even more intended for productive use. For this purpose, the name Mistpark was dusted off. The new stable branch was named #Mistpark2020 or simply #Misty. Misty was the first of its kind to not even get an announcement anymore, though. Its home page on Zotlabs disappeared along with Zotlabs before it could be filled with any useful information.
Two things were interesting: Red Matrix, Osada, Zap and Misty were based on various states of the same code base. It was possible to switch from one to another by rebasing the local code repository on your server. This became obvious through instances that carry the name of one project but run another one.
It must have been in 2021 when #Roadhouse showed up, again, unannounced. It seemed to be nothing more than a concept for the next generation of distributed social platforms. Roadhouse was the first of its kind to use the #Nomad protocol which, I guess, is forked from #Zot because it serves the same purpose. It got its own home page on Zotlabs which remained as uninformational as Misty's.
And then the most recent name popped up: #Streams. At first, it was even less clear what Streams was supposed to be and what set it apart from Roadhouse, not to mention Red Matrix, Osada, Zap and Misty, also because Zotlabs didn't say what Streams was either.
But I guess Streams' purpose has emerged in the meantime through word-of-mouth: It's the experimental successor of all five and the solution to this maze of names. Streams isn't even a product with a name, it's a concept that uses Nomad for nomadic identity and that is in constant flux, hence Streams. The idea was to do away with fixed names to get rid of the previous chaos. Everyone can name whatever they do with Streams however they want.
There is currently only one more or less public Streams instance, but it still carries "Stream" in its name. At least two more instances which may be private are named something with "Streams", too. So whether Mike wants or not, Streams has become a name of its own, and people use it.
How many Streams instances exactly exist right now is hard to tell, even from Communities pages on Streams instances or Sites pages on older platforms, because they don't necessarily identify themselves as Streams instances. So if you go through one of these pages, and there are names in the Projects column which you don't know as Fediverse platforms, check out what's behind them. It's often only one instance. Open the instance, click its burger menu, and if there's a Communities link, it's a Streams instance. I've discovered a lot of Streams instances not named anything with Streams this way. Private instances included, I guess Streams must have more than a dozen instances already.
There has even already been a request to launch a Streams support forum much like the one for Hubzilla; after all, Streams still supports forums. It's safe to say that Streams is doing quite well for something so obscure.
Feature-wise, Streams is the same as Zap and Misty.
But what became of the six platforms between Hubzilla and Streams?
- Red Matrix kept having only this one single-user instance because nobody else dared to touch it and set up another instance. It's a Zap instance now as far as I can see.
- Osada never really took off, Zap probably did only after Osada was merged into it, and some Osada instances became Zap instances. This explains why Zap has got comparably many instances. Most of them, however, are tiny, probably private and utterly undermaintained as they run rather old Zap versions. Zap only lives by numbers, and it's the only one of the five listed on Fediverse Observer. Also, while the FediDB lists all five, it only knows that one Dominican public Zap instance and none of the others (looking through its connected sites reveals many unlisted instances of Zot-based networks, by the way). Still, it seems to be on the deathbed, being superseded by Streams, experimental as the latter may be.
There still seem to be a very few running Osada instances, but Osada can be considered dead as the focus is on Streams now. - Misty didn't take off either, even though it was considered more stable and more production-grade than Zap. This time, the reason may simply be because Misty got zero advertising, so nobody heard about it, probably not even some of the Zap crowd. Misty never had many instances, they weren't properly advertised either (the same applies to most Zap instances, by the way), and Misty's death knell may have been the unannounced shutdown of its largest instance. Basically, there was little room for Misty next to less obscure Zap.
- Roadhouse didn't even manage to get much limelight before Streams appeared shortly afterwards. In both cases, the only way to find out what they were and what they did was by either studying the source code or installing a private instance. Streams, however, had the advantage of being even newer. The-Federation.info knows exactly one German Roadhouse instance which was originally set up as Misty and has meanwhile been upgraded beyond Roadhouse to Streams, and there only seems to be one remaining unlisted Roadhouse instance.
- I've seen another result of an upgrade from Zap to Misty. So it's safe to assume that you can upgrade all five to Streams. If this is the case, then now that Streams is here, it probably isn't worth spreading the developer community across six almost identical platforms. Basically, Streams has become the latest version of Red Matrix, Osada, Zap, Misty and Roadhouse.
- At least Red Matrix, Osada, Zap and Misty are still being maintained in a sense, though. All four got the same small Git commit from Mike a good month ago. Roadhouse got one four months ago.
As of now, Friendica is still going strong, so is Hubzilla, and Streams seems to be cleaning up the mess that came after Hubzilla.
If you really want to try out something with Zot, my current recommendation is Hubzilla, even if it may seem bloated and cumbersome to you, even if you'll never harness its full power. Many of its extra functions are additional apps and switched off by default; this includes ActivityPub, by the way, this is important to know.
It's hard to find a public Streams instance with open registrations currently, much less multiple ones that'd be required for a nomadic identity. Neither Fediverse.party nor the FediDB nor The-Federation.info nor Fediverse.info even knows Streams, and existing Streams instances usually don't identify to other Fediverse servers as Streams instances. It's still a rather underground and grass-roots project with no publicity at all. As Streams is rather experimental, however, you may want a nomadic home on at least two instances to have an instant backup, should one of them shut down.
Zap has got exactly one instance open to the public, and seeing as Zap may be shrinking rather than growing, I don't expect this to change. Again, due to Zap's still small size and unclear future, I wouldn't recommend using it without nomadic identity as a safety net.
As for Osada or Misty, good luck finding an instance to join, much less one that's here to stay and ideally be upgraded to Streams one day.
Hubzilla may not be as bleeding-edge as Streams, and it may be overkill for your purposes if Zap or Streams would be sufficient, but it's stable, it's big enough, it's established, and it's different enough from Streams to not be endangered by it. I mean, Hubzilla hasn't managed to kill off Friendica either, right?
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •on the plus side, I now have a not exactly adequate ESP32 board (ESP32-CAM from @Olimex, the -CAM bit is the reason why it isn't the right board for this :D ) that is currently going into deep sleep, waking up every almost-5 minutes and sending a message over MQTT that tells me that there are 18°C (hardcoded :D ).
I wonder if I should change it to 20°C to make it feel warmer :D
or rather, tomorrow I'll try to attach a DHT22 and fill in realistic values :D
hopefully the same #arduino code will work on the ESP8266 boards when I'll find them.
Olimex reshared this.
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •The DHT22 can't be read.
Possible causes:
* the DHT22 is dead
* I'm not powering it enough
* The ESP32 is not able to bitbang the DHT22 protocol
I think I'll stop here and resume the attempts later.
If I find the boards I originally wanted to use I can try to test the power issues (here I was using an unholy maze of jumper cables).
I may have planned to buy a DHT20 in the future (probably after the christmas holidays, however, and for sure after this weekend), so if it's an issue with bitbanging the DHT22 protocol that will get a different solution.
And I may try to connect the DHT22 to some other board to check whether it's still alive, but probably not today.
#microcontrollers
Damiano Verzulli
in reply to Elena ``of Valhalla'' • • •:
say that it operates within a 3.3V-6V . How are you powering it?👉 "the DHT22 is dead": very unlikely, unless you "burned" it... Did you?
👉 "I'm not powering it enough": the datasheed
👉 "The ESP32 is not able to bitbang the DHT22 protocol" : there should be battle-tested libraries dealing with the DHT22. Which one are you using?
-----
sparkfun.com/datasheets/Sensor…Elena ``of Valhalla''
in reply to Damiano Verzulli • •@Damiano Verzulli
* the DHT22 has been in a drawer for years: I don't think I would have put it back in the drawer if it had been burned, but who knows
* as I said, I'm powering it through an unholy ratnest of jumper cables. it should provide 5V, but an earlier attempt at powering it at 3.3V with a bit less of a ratnest only provided 2.something V, and with the 5V I didn't have room to actually measure it without breaking the ratnest and disconnecting everything (yes, I tried).
This is caused by the way the board I'm using is being powered (through the programmer, on the single available 5V pin), and since I'm not planning to use this specific board anyway I've decided it's not worth spending any more time.
* I'm using the library from Adafruit, it was their documentation that recommended¹ trying things with an arduino uno first, as on some boards it didn't work (but it didn't have a list of working boards, or at least it wasn't directly linked).
¹ following recommendations? from the documentation? NEVER :D the documentation is only skimmed to find the syntax to use :D
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •Last week we might have received a few ESP32-C3-DevKit-Lipo, yesterday I promptly managed to semi-brick one of them while programming them via arduino.
To avoid that semibricking, the right board to use is ESP32C3 Dev Module, AND you need to enable USB CDC On Boot
And to avoid panicking, bringing GPIO9 to GND will set the board into bootloader mode :D
rag. Gustavino Bevilacqua reshared this.
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •Then, with the board nicely sitting on a breadboard, a stable 3.3V and no ratnest of jumper cables I've seen that the code I wrote last week works: the board turns on, connects and sends the temperature and humidity data from the DHT22 on mqtt, sets a timer and goes into deep sleep.
As long as you don't use Serial.flush(); before going into deep sleep, otherwise it will hang on it until it *gets* a serial, or something, and it will not have a serial while running on battery (uooops).
(yes, the DHT22 seems to be working fine on 3.3V, probably as long as it's close enough to the board that the voltage isn't dropping. and I'm not going to have 5V while on battery, so 3.3V it is)
rag. Gustavino Bevilacqua reshared this.
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •The Bag of Random Sensors that had the DHT22 also gifted me with 3 (THREE!) BMP280 (temperature and atmospheric pressure, I2C or SPI).
While playing with them I've learned:
* The #esp32c3 can use #i2c on any pin; the default I believe is 8 and 9, but they are also used while programming, so meh
* You can change the i2c pins in #arduino by calling Wire.setPins(I2C_SDA, I2C_SCL); before any Wire.begin();
* There is an example sketch called Wire -> WireScan which scans for i2c devices (you will have to change it to use the pins you want to use with a call to Wire.setPins) which is a godsend.
reshared this
rag. Gustavino Bevilacqua reshared this.
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •aaaand, temperature and pressure have been read.
for some reason, however, right now arduino isn't compiling the sketch twice in a row (with the error “panic: runtime error: index out of range [9] with length 9”).
But I'll look into it probably during the Christmas holidays, for today I'm ok with this.
Elena ``of Valhalla''
in reply to Elena ``of Valhalla'' • •oh, right. I was supposed to look into the arduino failures.
instead, I've looked a bit at the python side of things, and surprisingly what I did worked fine, even if it wasn't much.
Larry (Mr.Optimization)
in reply to Elena ``of Valhalla'' • • •The whole ESP32 family can do hardware I2C on most of their bidirectional GPIO pins. I2C is a relatively simple protocol that can be simulated in software on any GPIO pin on any MCU (FYI):
github.com/bitbank2/BitBang_I2…
GitHub - bitbank2/BitBang_I2C: A software I2C implementation to run on any GPIO pins on any system
GitHubElena ``of Valhalla'' likes this.