A lot of work for what reason?

I understand the approach behind the question. There is also confusion when people talk about Zot and Nomad at the same time.

However, I don't see any real necessity. I'm still not sure why Mike renamed Zot.

Zot is an established term. Nomad, on the other hand, is not. When I first read about Nomad as a protocol, web searches led me to pages about ‘something to do with blockchain and digital wallets’. For me, that's actually the moment when I stop. Now the hits in the search had nothing to do with the Nomad protocol from e.g. (streams)... but it can contribute to confusion. A search for Zot, on the other hand, leads to information about Hubzilla's communication protocol... so it fits.

And there is even a ‘Zot protocol community group’ at W3C. 😉

My personal opinion: stick with the term ‘Zot’ and avoid ‘Nomad’ as far as possible in connection with Hubzilla.

Up until this point, the development of the protocol has been somewhat linear. It was called Zot when Hubzilla implemented it, and the version we use is Zot 6. Mike kept on developing new versions of Zot, but Hubzilla stayed with Zot 6. And then at some point Zot was rebranded as Nomad. Because of this name change, one could argue that we are running Nomad 6. And that seems to be Mike's argument.

Following this linear timeline, Zot and Nomad are the same thing, and it is just a matter of what we prefer to call it.

But the upcoming version of Hubzilla 10 is going to update Zot 6 to support Mike's conversation containers rather than upgrade to the latest version of Nomad.

What that means is that the progression is no longer linear. Zot 6.1 (or whatever you want to call it) is effectively a fork. A small stubby one, but a fork none-the-less.

So, the question becomes, is Hubzilla going to eventually adopt Nomad 12 (or whatever version it is now), or are we going to continue to modify Zot 6 so that it deviates into being a separate protocol from Nomad/Zot6?

Edit: inaccurate information struck out.

It also should be noted that what you call it internally in the software does not have to be the same was what you call it publicly and in documentation.

But before we decide what to call it, we need to decide whether we will eventually upgrade or fork. If we upgrade, then it becomes Nomad. If we fork, it should not be called Nomad to avoid confusion.

Unless we want to do some sort of "Nomad family of protocols" sort of thing.

@Der Pepe (Hubzilla) ⁂ ⚝ Nomad isn't ZOT6 for one (is it 11 or so?) - however the renaming kind of reflects the fact, that it is one love developer working on it somehow. No pun intended whatsoever, and happy, when people work with such stringence otherwise. However, team work seems to lead to more long-lasting and more widely accepted work in general.

@Scott M. Stolz I guess, that (streams) is already - and now not anymore - a Hubzilla fork, so it seems just logical, that the language was developed separately as well. I prefer, when Hubzilla goes it's own way there for the simple reason, that readapting a former fork might cause more trouble, that a thourough analysis of the good things, that have been found there - and then coding the good stuff again into the new version of Zot6.

@_jayrope It's interesting. Streams is a fork of Hubzilla, and by adding conversations containers to Zot6, we are basically forking Nomad/Zot by doing so.

Edit: Inaccurate. Post will probably be deleted.

@Scott M. Stolz

we are basically forking Nomad/Zot by doing so

I would rather call it a "backport".

@Scott M. Stolz

But the upcoming version of Hubzilla 10 is going to update Zot 6 to support Mike's conversation containers rather than upgrade to the latest version of Nomad.

That is not a change at the protocol level :thinking_face:

Another relevant question is the future of Nomad. Mike said he retired from working on Streams, and he is now working on a project called Forte that does not even have Nomad or Zot6 in it.

If Nomad is no longer being developed, and we are the only actively developed project still using it, then how does that affect things? If that is the case, does that mean we become the de facto maintainers of the protocol?

I hope that Mike continues to develop Nomad and Streams, but his latest announcements seem to indicate otherwise. Hopefully he is just taking a break and will come back to Nomad and Streams.

@Scott M. Stolz It's a drag, that these eventualities depend upon the unforeseeable decision development of just one person (as much as i appreciate this person's work, really!). Not a sustainable concept this way.

@Scott M. Stolz

So, the question becomes, is Hubzilla going to eventually adopt Nomad 12 (or whatever version it is now), or are we going to continue to modify Zot 6 so that it deviates into being a separate protocol from Nomad/Zot6?

(..)

If we upgrade, then it becomes Nomad.

When i read this i wonder what is meant by that... are you actually aware of the differences of ZOT and Nomad?
Would an upgrade make sense or is it even possible in the first place to upgrade HZ to "Nomad" without loosing part of what HZ is?

After all there were significant reasons why Mike started a new project and found a new name for the protocol he rewrote in parts. - Just a guess.

I`m not able to tell what the differences are, maybe someone can explain - would be kind. Thanks.

I also ‘quickly’ tried to grasp the differences. You can forget it. Converting Hubzilla to Nomad would probably be a very, very complex project. Is it worth it? I have no idea.

In my opinion, it should be limited to keeping Zot as Zot (Zot7, Zot8, Zot9...) and only transferring the appropriate and useful parts from Nomad to Zot. This is easier to manage and would prevent a break in Hubzilla's compatibility and functionality.

A look at the specifications of Zot6 and Nomad does not reveal the actual differences.

@Scott M. Stolz Whatever Mike changes on Forte, he changes on (streams) as well. Exceptions may exist for Forte-specific code, but there's rather (streams)-specific code than Forte-specific code.

For example, Uafilter was introduced to Forte and (streams) all the same AFAIK.

@Der Pepe (Hubzilla) ⁂ ⚝ Zot8 was developed with the third Osada, Misty and Redmatrix 2020, so that's taken.

Nomad as of Roadhouse (which I assume was the first to be based on something that was no longer compatible with Zot6) would have been Zot11 if it still was Zot. Nomad as of (streams) would be Zot12 if it still was Zot.

Still, we'll have to wait for a statement from Mike on how to name his stuff. But keep in mind that Mike has a strong aversion against brand names and brand worship culture.

@Der Pepe (Hubzilla) ⁂ ⚝

A look at the specifications of Zot6 and Nomad does not reveal the actual differences.

??? ... the documents seam almost identical

Zot is not a ‘brand name’, but a name for a protocol. What else should we call it? ‘A protocol’ perhaps?

Mistpark, Osada, Zap etc. are dead. Since the name Zot finally came to an end with version 12 (and has been called Nomad since then and had developed incompatibly anyway), it would only make sense to name the further development of Zot6 either by skipping the version numbers up to 12 and making it Zot13 (nothing against the 13, that's a completely normal number 😉), or to continue with Zot61, Zot62 etc. in order to keep the ‘6’ as the root of the new Zot branch.

@𝓒𝓱𝓻𝓲𝓼

the documents seam almost identical

Of course!

I ran diff over it yesterday. The differences are minimal (rarely a sentence change without changing the statement) and almost only the replacement of the word ‘Zot’ or ‘Zot6’ with ‘Nomad’.

so there are different names and follow up projects with different features but still no one here could name me the actually differences which the protocol make and what part they have by the noticeable changes

Well, a notable difference is that you in streams can post using markdown, BBCode, and also html, using zot just the first 2.

@Giac El Vecio

using zot just the first 2

Are you absolutely sure about
that?

So if I use HTML to write a post, then that works too. It is converted to bbCode anyway.

Are you absolutely sure about
that?

So if I [b]use[/b] [size=large]HTML[/size] to write a [i]post[/i], then that works too. It is converted to [url=https://hzhelp.pepecyb.hu/en/usermanual/bbcode.html]bbCode[/url] anyway.

Is not the same, you can use pure html.

Now it works yes ,also in hz, I tested months ago and didn't work, when I tried to explain this for friend.

In the early days of nomad,
i asked Mike what the difference was between zot and nomad and he answered in a comment, if you want to look for that conversation...i don't even remember if it was a conversation started in a forum or not, but i remember a part where he says he didn't want to "put all the cards on the table" where everyone could see "our secrets" or something like that 😆

@𝓒𝓱𝓻𝓲𝓼

I`m not able to tell what the differences are, maybe someone can explain

I am not sure of the differences, but I was told that the latest versions of Nomad are not backwards compatible with the version 6 that Hubzilla is using. This is why Streams ran both the latest version of Nomad, and also ran Zot6. The latest version of Nomad cannot talk to Hubzilla.

It would be a significant project to upgrade to the latest stable version of Nomad.

@Der Pepe (Hubzilla) ⁂ ⚝

I would rather call it a "backport".

That is probably the most accurate description.

@Jupiter Rowland

Whatever Mike changes on Forte, he changes on (streams) as well.

I hope that is not the case, because Forte does not have Nomad or Zot6 at all. It is pure ActivityPub.

I was hoping that:

Streams = ActivityPub, Nomad, Zot6
Forte = ActivityPub

Just to be complete:

Hubzilla = ActivityPub, Zot6

@Scott M. Stolz I don't mean he makes (streams) a Forte clone by ripping Nomad and Zot6 out. That'd be non-sense.

What I meant is:

If Mike fixes a bug in Forte, he fixes it in (streams) just as well.

If Mike builds Uafilter (the instance-level user agent filter that's capable of entirely locking Mastodon out, for example) into Forte, he builds it into (streams) just as well. Because he has actually done so.

He leaves Nomad and Zot6 in. Otherwise, whatever he fixes or improves in Forte, he fixes or improves in (streams) just as well.

There's a big field between making (streams) and Forte as identical as Misty, Redmatrix 2020 and the last Osada used to be and completely abandoning (streams).

@Jupiter Rowland If that is the case, then Streams is still supported, even if it is not Mike's primary focus right now.

In all fairness, Mike did develop the protocol, and he has picked a name for it.

But, I do think it would be a mistake to stop calling Hubzilla's version Zot or Zot6.

As mentioned earlier, when you search for Nomad, you get something else entirely.

I wouldn't be opposed to calling Hubzilla's version Nomad/Zot6 or something similar, and calling the latest version Nomad. But I don't think we should drop the name Zot, for a variety of reasons.

One of those reasons is that version 6 is not compatible with the latest versions of Nomad. If both were called Nomad, that could cause some confusion, since the latest version of Nomad can't talk to Hubzilla.

One possible solution is:

1. Stop using the term "Zot Protocol" since it implies that it is a separate protocol.
2. Use "Nomad protocol" when referring to the protocol in general.
3. Use "Zot6" or "Nomad/Zot6" when referring to the version that Hubzilla uses.
4. Avoid using the term "Zot" by itself, since you need context to know what it means.

Would something like this be acceptable?

By the way, I have the domain name opennomad.net registered. I could easily put information about the Nomad protocol and Nomad/Zot6 on that website. That way we show up in the search results, and we have a website we can send people to that explains what it is.

But, I don't know much about the history of Nomad/Zot, and I am not familiar with the technical specs. I would need help writing content for that websites.

If anyone wants to collaborate with me on that, it would be appreciated.

@𝓒𝓱𝓻𝓲𝓼

the documents seam almost identical

You can't go by the documents. Those are usually the last thing that gets updated.

It is all about communication :-)

The term which makes things more clear and gets understood by the relevant folks the best may be the term to use.

Time after time the significant parts of Nomad will get part of AP and Nomad will dissolve and vanish as an own protocol - this is the project Mike is working on.

How will HZ follow here or will take its own path and place?

If we want to emphasize that HZ has and will have it's own protocol than the term ZOT is just right.

If we want to make clear that HZ uses since a long time parts of the technology which in the future will become a feature by other apps as well ( in that what is called the Fediverse ) than it may be not a bad idea to use Nomad as term because that is the name other devs may understand the best, without studding all the history.

But for what does the protocol stand at the end anyway?

For instants: streams has few more permissions to apply - how does this option depend on Nomad or could the changes be part of HZ as well without touching the protocol?

or

The HZ and streams IDs can´t be ported and cloned between each other any more - is this because of the protocol or because of other reasons?

I do not know and can't tell, but we should know.

It is all about communication.

Mike explained to me a while ago:

Nomad sends messages encoded in ActivityStreams (the same serialisation format used by ActivityPub). As does Zot6. So technically the only difference between an ActivityPub message and a Nomad message and a Zot6 message is that they use different delivery services. In the case of Zot6 and Nomad, these delivery systems support nomadic identity.

So according to this statement "just" the nomadic identity feature makes all the difference.

@Scott M. Stolz Nomad-actually-Zot11, which Roadhouse was based on (the early 2021 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020 from which, in turn, (streams) was forked), was already incompatible with Zot6. This was the reason why Mike no longer called it "Zot" in the first place.

(streams) has arrived at Nomad-actually-Zot12.

This is how I've understood the post-2015 history:

Name	Created	Forked from	Protocols	Discontinued
Osada¹	2018	Hubzilla? Zap?	Zot6 ActivityPub diaspora*? OStatus?	2019
Zap	2018	Hubzilla? Osada?	Zot6 ActivityPub since 2019	2022-12-31⁶
Osada²	2019	Zap	Zot6 ActivityPub	2019
Hubzilla	2015	(MIT) Friendica	Zot (Zot6 since 2020) ActivityPub diaspora* OStatus etc.
Osada³	2020	Zap? Misty? Redmatrix 2020?	Zot8 ActivityPub	2022-12-31⁶
Mistpark 2020 (a.k.a. Misty)⁴	2020	Zap? Osada? Redmatrix 2020?	Zot8 ActivityPub	2022-12-31⁶
Redmatrix 2020⁵	2020	Zap? Osada? Misty?	Zot8 ActivityPub	2022-12-31⁶
Roadhouse	2021	Osada? Misty? Redmatrix 2020?	Zot11 Nomad Zot6 ActivityPub	2022-12-31⁶
(streams)	2021-10	Roadhouse	Zot12 Nomad Zot6 ActivityPub
Forte	2024-08	(streams)	ActivityPub

¹First Osada. Intended as a "bridge" between Zot6-only early Zap and the rest of the Fediverse. No nomadic identity. Didn't work out.
²Second Osada. Started out as Zap with ActivityPub. After Zap itself got ActivityPub, it was Zap with ActivityPub on by default whereas Zap had ActivityPub off by default. Discontinued because identical in code with Zap.
³Third Osada. Allegedly "Zap unstable" with ActivityPub on by default. Actually identical in code with Misty and Redmatrix 2020.
⁴Allegedly "Zap testing", more stable than Osada, but fresher than Zap. Actually identical in code with Osada and Redmatrix 2020.
⁵Allegedly "Zap unstable" with ActivityPub off by default. Actually identical in code with Osada and Misty.
⁶Officially superseded by (streams)

My current idea: I would leave it as it is for now, even if there might be a little confusion here and there about whether and how Nomad and Zot are connected. I think that's negligible.

I also believe that we are making the mistake here of equating the actual protocol and the implementation. A communication protocol only describes the rules for communication between servers. How this is ultimately implemented in code is independent of this. In my opinion, however, the published specifications are quite sparse as far as the concrete syntax is concerned. This is not an accusation against Mike, but quite normal that the person who develops such a protocol does not present many things abstractly enough for others ‘because he himself knows exactly how it is meant’.

As I said, I think the equation is unfortunate.... but nevertheless it inevitably results from the naming of the libraries, the programme routines that ultimately implement the protocol. It is completely logical and natural that if the protocol is called ‘Zot’, routines and libraries are somehow also called something with ‘Zot’. This makes it clear what they do... namely to implement communication based on the Zot protocol as software.

As far as I know, the fact is:

After Mike left and handed over the Hubzilla project, the protocol (in the above sense, i.e. not the software implementation) of Hubzilla was and is Zot6. And it still is today. I don't know whether the specification for the actual protocol was also changed for changes, improvements and new functions (of the software, and thus also of the libraries/routines). I suspect that this did not happen. New features were only a programmatic matter, but they utilise and adhere to the original protocol.

It is probably also a fact that Nomad is possibly a completely different protocol (with regard to the technical specifications, which unfortunately cannot be found anywhere). This seems to be the case because there are clear incompatibilities.

The question is whether the actual protocol was changed in the technical specification during Mike's further developments with and after Osada, Zap (and whatever the projects were called). Were there new protocol specifications, or was it also the case that the consecutive numbering was more due to the implementation of new functions based on the protocol in the form of new routines?

In any case, as I see it, Hubzilla actually has nothing to do with Nomad, and I don't see ‘Nomad’ as a general umbrella term for Zot and the actual Nomad protocol, because that doesn't correspond to the facts. Zot is Zot and Nomad is Nomad.

This could also lead to real problems. If we say Hubzilla also uses a ‘Nomad protocol’ (a, not THE), and someone (whether from the original repo or a fork) sets up a ‘(streams)’ instance. Presumably he (and users of the Hub) will be disappointed if it doesn't interact with Hubzilla as hoped (cloning, for example).

Oh... and we really shouldn't orientate ourselves on all the projects (Zap, Osada... etc.) that only had a short lifespan. The protocol versions (or are they just software versions that always implement the same technical protocol?) are now meaningless because the projects have effectively been cancelled and are hardly running anywhere.

@Der Pepe (Hubzilla) ⁂ ⚝

After Mike left and handed over the Hubzilla project, the protocol (in the above sense, i.e. not the software implementation) of Hubzilla was and is Zot6.

Well, Mike handed Hubzilla over in 2018 to work on Zot6 using Osada and Zap. Since he handed Hubzilla over to have time to work on Zot6, Hubzilla can't have had Zot6 yet at this point.

Zot6, along with OpenWebAuth, was developed on two Osadas and Zap. Along with the second Osada and Zap, it matured to stable in 2019.

It was Mario who backported both Zot6 and OpenWebAuth into Hubzilla, and that was in 2020.

It is probably also a fact that Nomad is possibly a completely different protocol (with regard to the technical specifications, which unfortunately cannot be found anywhere).

"Completely different" implies that it was rewritten from scratch.

There are still similarities. After all, Roadhouse's early Nomad was originally intended to be named Zot11.

But the advancement to Zot11 required cutting off backwards compatibility with Zot6 and redesigning things in ways that Zot6 is not compatible with. It was this incompatibility that was the reason to no longer refer to Zot11 as Zot, but to rename it Nomad from this point on.

What I think (if anyone is interested):
having 2 different protocols was nice and useful, having a single protocol used by incompatible platforms (incompatible at 25% or 40% or more) is believing in a utopia of a perfect fediverse in terms of communication and results, so it is finding yourself in a sea of ​​trouble.
Having a single protocol means being exposed to an ocean of shit.
You can invent something powerful to keep this shit out, ok, but this translated means: communicating with just 5 or at most 10% of existing projects.
So it's a bit like going back to square one.

@Der Pepe (Hubzilla) ⁂ ⚝

My current idea: I would leave it as it is for now, even if there might be a little confusion here and there about whether and how Nomad and Zot are connected. I think that's negligible.

A website probably would help. That could explain:

The nomad protocol itself, and the two current implementations, Nomad 12 and Zot 6.

Some specs would be nice to publish too. The docs that come with Hubzilla isn't as thorough as I'd like, and I am not sure of the state of the docs in Streams and Forte.

The benefit of doing this would that we would be acknowledging that both implementations use the Nomad protocol, but we can still refer to Hubzilla's implementation as Zot 6.

And I stop calling it the Zot Protocol, which is what I think Mike was objecting to.

One question floating in my head is this: If they are the same protocol, why are they incompatible?

Is it simply lack of if then statements to detect whether the other version supports a certain feature, or has the protocol itself changed.

For example, a lot of platforms are running very different versions of ActivityPub, yet they can talk to each other regardless, albeit with varying levels of support for certain functionality.

Is it the implementations that are incompatible, or is it a protocol change that made it incompatible?

@Scott M. Stolz

And I stop calling it the Zot Protocol, which is what I think Mike was objecting to.

Where and how did Mike say that he rejects the continued use of the term ‘Zot’? Or does that just mean ‘Zot’ (without the number behind it) and not ‘Zot6’? Would he have no objection to the use of the term ‘Zot6’?

...I am not sure of the state of the docs in Streams and Forte

Have you ever looked at the documentation for streams and Forte? That's not nothing, but it's not really enlightening either.

The Forte documentation has probably not even been touched since the fork of Streams. For example, there is still a file with the description of the Nomad API in the Develop area, even though Forte has thrown out Nomad.

Is it the implementations that are incompatible, or is it a protocol change that made it incompatible?

I have no proof of this, but I strongly suspect that the incompatibility of the services used by Zot6 and Nomad is not due to the protocol, but to the implementation.

Unfortunately, this is not so easy to check. You would have to analyse the respective program codes in detail and see whether they really generate/process incompatible data due to the protocol. Unfortunately - and I repeat myself - there is no technical specification of the two protocols.

In this comment I talked about Zot-Nomad and activitypub, and not zot vs nomad, just to be clear 😉
And also about the possibility of having just activitypub in the next years (also in hz streams forte.  ..), hz friendica streams and probably forte are so so different comparing with mastoverse/microblogs platforms, we can have the same protocol, but never a good and complete communication-federation.

@Der Pepe (Hubzilla) ⁂ ⚝

Where and how did Mike say that he rejects the continued use of the term ‘Zot’? Or does that just mean ‘Zot’ (without the number behind it) and not ‘Zot6’? Would he have no objection to the use of the term ‘Zot6’?

The context behind it was that I was calling it Zot protocol in some documentation. Unless he further clarifies, I am going to assume that he is objecting to me calling it "Zot Protocol" instead of "Nomad Protocol."

As far as I know, he has not stated anything against using Zot6 to indicate Hubzilla's version.

This is his post:

https://fediversity.site/display/?mid=https%3A%2F%2Ffediversity.site%2Fitem%2F8a1221fb-1521-49c7-b789-aa32bf576cd6

In this topic:

https://authorship.studio/channel/scott?mid=d10e902b-cb98-4e89-8ef0-5794f6b5b961

I originally called it Zot Protocol in this document:

https://codejournal.dev/wiki/scott/Hubzilla/ActivityPub

@Mike Macgirvin 🖥️

The underlying protocol is now called Nomad. Has been for a few years now.

'Zot6' is sometimes mentioned in discussions with Hubzilla folks to distinguish that project's frozen protocol implementation (nearly always displayed as 'Zot6/Nomad'); but if you're speaking in general terms about the underlying nomadic protocol in documentation, be advised that some folks in the fediverse get pretty riled up over dead-naming.

@Scott M. Stolz

With a fresh head in the morning, in the context of what I wrote yesterday (writing something down often helps to sort your thoughts) and the comment Mike wrote (I had seen it, but hadn't realised the actual statement behind it), I now have a fairly concrete idea, which I will put into words here again (not now, for now the dogs and horses demand my love and care 😉).

@Mario Vavti could you point us to snipe of code where ZOT is active and mark the lines for us? That would be kind. Thanks

Than we could have a look into the steams repo and find out what is different

I have now interpreted it like this...

Mike has communicated very clearly: The protocol that used to be called Zot is now definitely called Nomad.

He also distinguishes between the protocol and the implementation in a software and mentions the implementation of the protocol with the name ‘Nomad’ at Hubzilla in the software modules and libraries that bear/contain the name ‘Zot6’ (‘...that project's frozen protocol implementation...’). He acknowledges, but does not contradict, the fact that ‘Zot6’ or (as is now more common) ‘Zot6/Nomad’ is spoken/written in connection with the code.

So we have a communication protocol called ‘Nomad’ and we have the protocol implemented in Hubzilla, which is done by libraries and functions with the name ‘Zot6’.

In my opinion, this means that it is irrelevant what the programmed implementation of the protocol is ultimately called. The user is not interested in this either (I don't care what name any function in the source code of an application that I use has). And it follows that we would have to replace the word Zot with Nomad in all public documents (project page, help pages, info pages, etc.) if we are referring to the protocol. And that is what we are referring to almost exclusively. Only in the developer documentation should the term ‘Zot’ or ‘Zot6’ or more precisely ‘Zot6/Nomad’ appear, because the code parts simply have this name.

I am of the opinion that renaming in the code is out of the question because it would be a very risky (and possibly also lead to backwards compatibility problems) and extremely costly thing to do (is disproportionate to the benefit and would tie up developer capacities that would be much more important for other things).

I also see a clear advantage in the fact that the software implementation of the Nomad protocol does not also have "Nomad" in its name: the clearer separation of the protocol and the software implementation of the protocol. This has led to confusion in the past (yes, even today). When Mario added new functions to Hubzilla that represented a permitted implementation of the protocol, many people had the feeling that Zot6 had been expanded and a new version had arrived. However, the protocol has not changed at all, only the library, which provides new functions based on the same protocol.

Are these thoughts understandable? Am I wrong somewhere?

@Der Pepe (Hubzilla) ⁂ ⚝

I also see a clear advantage in the fact that the software implementation of the Nomad protocol does not also have "Nomad" in its name: the clearer separation of the protocol and the software implementation of the protocol.

If it does not have Nomad in its name, does it bear a name? What is the name of Stream's implementation of Nomad? That might be useful to know if we are to refer to the protocol as Nomad and the implementations as Zot6 and ____?

@Scott M. Stolz

For Streams the corresponding file is called NomadHandler.php and for Hubzilla Zot6Handler.php:



However, I think we could (and should for the reasons mentioned) stick with Zot6. Mike probably named the handler library after ‘Nomad’ because he renamed the protocol the same way. But in the end, it doesn't really matter what the programme files are called. For Hubzilla, the Zot6 routines are the ones that implement the Nomad protocol in Hubzilla. The name can be left as it is for ‘historical reasons’.

Mike Kutetz shows Nomad and ZOT as two different protocols. :-(
__

Ich weise ihn mal darauf hin, dass Zot auch Nomad heißt (unter Verweis auf die Assage von Mike, wo er das ja explizit so geäußert hat).

hab es gerade schon in dem thread gepostet

Bin mal gespannt...

Im Endeffekt müsste er nicht mit unterschiedlichen Farben etc. arbeiten, sondern einfach nur Nomad nennen. Die interne Bezeichnung der Bibliothek, welche das Protokoll umsetzt, interessiert niemanden und will auch keiner wissen.

Also z.B. so:

@Der Pepe (Hubzilla) ⁂ ⚝ na ja wenn gar nicht mehr ZOT genannt wird, ist auch verwirrend weil die HZ DEVs ja auch ZOT weiterhin als Begriff gebrauchen

@Der Pepe (Hubzilla) ⁂ ⚝ Since both Streams and Hubzilla support Zot6, and it is version 6 of the Nomad protocol, we could say Nomad / Zot6 in the diagram, at least as a transition. Because basically, Streams supports the latest version, and Hubzilla supports version 6 (Zot6).

@𝓒𝓱𝓻𝓲𝓼 @Scott M. Stolz

That seems ok to me so far (so write Nomad/Zot6+). Ultimately, however, the name Zot is just the name of the library that implements the Nomad protocol.

@Der Pepe (Hubzilla) ⁂ ⚝ I think that once we update the documentation, where it mentions both the Nomad Protocol and the Zot6 implementation of the Nomad Protocol, then when people look up either one, they can find an explanation on how they are related.  

Once we have the docs up, we can start calling it just Nomad.

As a side note, I purchased the domain name opennomad.net and would like to eventually turn it into a Hubzilla site with information about Nomad Protocol and Zot6.

@Scott M. Stolz
I think your idea regarding the procedure is a smart one. That's how we should do it.

I'll think about the best way to incorporate and implement this in the help (current status of the new version). I already have some ideas.