panic room plus - Datenschutzanstalt für den Wiederaufbau der Privatsphäre

Fri, 10 Sep 2021 13:39:07 +0000

neue medienordnung plus schrieb den folgenden Beitrag Fri, 10 Sep 2021 13:39:06 +0000

Fix the problem of PhantomID's sustainably

Hi,

I think it is important to fix the PhantomID bug https://framagit.org/hubzilla/core/-/issues/1608. In my opinion, this error significantly damages the image of the Hubzilla project. Hubzilla makes the claim:

allows anybody to publicly or privately publish content via "channels", which are the fundamental, cryptographically secured identities that provide authentication independently of the hubs which host them.

/help
and the PhantomID error demonstrates the opposite of this. In other words, you can never be sure from whom a contribution originates. At this point at the latest, it is no longer credible in my eyes to advertise Hubzilla with "cryptographically secured identities that provide authentication independently of the hubs which host them".

Please vote to fix bug #1608!

= German language =

Den PhantomID-Problem nachhaltig lösen

ich halte es für wichtig, den PhantomID-Fehler https://framagit.org/hubzilla/core/-/issues/1608 zu beheben. Dieser Fehler beschädigt m.E. das Image des Hubzilla-Projektes erheblich. Hubzilla erhebt den Anspruch

ermöglicht es jedem, Inhalte öffentlich oder privat über "Kanäle" zu veröffentlichen, die die grundlegenden, kryptografisch gesicherten Identitäten darstellen, die eine Authentifizierung unabhängig von den von Ihnen gehosteten Knotenpunkten ermöglichen.

/help

und der PhantomID-Fehler demonstriert m.E. ein Gegenteil davon. Sprich, man kann nie sicher sein, von wem ein Beitrag stammt. Spätestens an dieser Stelle ist es in meinen Augen nicht mehr glaubwürdig mit "cryptographically secured identities that provide authentication independently of the hubs which host them" für Hubzilla zu werben.

Bitte stimmt für die Behebung des Bugs #1608 ab!

#PhantomID #ChameleonIdentity #IdentityObfuscation

mehr anzeigen 39 Kommentare

Aksel Kies Linc @Hz

Fri, 10 Sep 2021 13:48:36 +0000 zuletzt bearbeitet: Fri, 10 Sep 2021 13:48:52 +0000

Did you see the comment on framagit? ->

Mario
Mario @Mario Vavti · 5 hours ago
Owner

As mentioned in various threads: this was a bug in Hubzilla caused by incomplete data. This has been fixed in a DB update quite a while ago. If you still suffer from this issue you can fix your data by visiting /fhubloc_id_url as the site admin.

neue medienordnung plus

Fri, 10 Sep 2021 14:54:05 +0000

@Aksel Kies Linc @Hz But here say @Mario Vavti

there is no guarantee that the error will not happen again

es gibt keine Garantie dass der Fehler nicht wieder passiert

neue medienordnung plus

Fri, 10 Sep 2021 15:06:09 +0000

PhantomID bug nullifies this key Hubzilla promise:

cryptographically secured identities that provide authentication independently of the hubs which host them

Status now: the ID/authorship of a message not only depends on which channel this message is viewed on, but can obviously occur completely randomly at any time - as long as the cause is not found and removed.

Mario Vavti

Fri, 10 Sep 2021 17:38:56 +0000

@neue medienordnung plus

as long as the cause is not found and removed.

As mentioned, the cause is found and removed. But nobody can guarantee that this or other bugs will not happen anymore. Hence there is this: https://framagit.org/hubzilla/core/-/blob/master/LICENSE

PhantomID is not just any bug after all

neue medienordnung plus

Sat, 11 Sep 2021 06:05:47 +0000 zuletzt bearbeitet: Sat, 11 Sep 2021 06:09:06 +0000

PhantomID is not just any bug after all. But a bug, because of which the key Hubzilla promise, unique sellingpoint of Hubzilla "cryptographically secured identities that provide authentication independently of the hubs which host them" end in smoke.

Artikel ansehen

@Mario Vavti

As mentioned, the cause is found and removed. But nobody can guarantee that this or other bugs will not happen anymore. Hence there is this: https://framagit.org/hubzilla/core/-/blob/master/LICENSE

I don't expect there to be no bugs in Hubzilla programs. Errors in programming menus, for example, are annoying and lower the acceptance of Hubzilla, but less critical and do not prevent advanced users from benefiting from Hubzilla's advantages.

I would like to limit the conversation to specific bugs related to the creation of FantomID's.
It's not just any bug after all. But a bug, because of which the key Hubzilla promise, unique sellingpoint of Hubzilla cryptographically secured identities that provide authentication independently of the hubs which host them end in smoke. I would have no understanding if this bug is treated like any other bug let alone pushed aside.

I would like to understand how this specific bug came about. Very helpful in this context might be to know:
1) how was this error discovered? Where can I read any error description in addition to the error #1608 I reported?
2) What was identified as the cause of the error?
3) What does the workaround fhubloc_id_url [2] contain - please describe here compactly what was then realized with the program code [2].

I see in [2] entries DELETE FROM operations. Is it correct that in this example from [2].
$r0 = dbq("DELETE FROM xchan WHERE xchan_hash = ''");
hubloc_id_url records WHERE xchan_hash = ''" are deleted? Can someone tell me what is stored in hubloc_id_url? Maybe a URL to the fediverse ID? So for example to a diaspora account?

[1] FakeIdentity, ChameleonIdentity, IdentityObfuscation, 10.09.2021 - https://framagit.org/hubzilla/core/-/issues/1608
[2] fix missing or hubloc_id_url entries, 12.05.2020 - https://framagit.org/hubzilla/core/-/blob/master/Zotlabs/Module/Fhubloc_id_url.php

Mario Vavti

Sat, 11 Sep 2021 08:21:37 +0000

@neue medienordnung plus basically what we do when a comment or post arrives via diaspora or activitypub (after the payload was cryptographically verified) is, we check if the sender also has a zot id. If there is a zot id for the sender, we swap the id that we got with the zot id. That is where things went wrong. Some hubloc entries were incomplete and therefor a random id was selected. In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.

If the updates since 4.6 were executed correctly, like described in the release notes, the issue should be fixed without manual interactions required.

There was no issue on framagit for this bug because nobody opened one. The issue was reported via Hubzilla. We could reproduce it and provided a fix.

@neue medienordnung plus it would be good if you report back on the issue if execution of fhubloc_id_url fixed the issue for you too.

In general it is hard and timeconsuming for developers if a issue report is scattered over X threads and a framagit issue. I kindly ask you to keep the information at one spot. Preferably the framagit issue tracker.
Also spreading unqualified opinions about what the issue is, does not help to solve the issue. In fact i have answered your initial post some minutes after it was posted with the info about what the issue is and how to fix it.

Malendur

Sat, 11 Sep 2021 08:25:03 +0000

But nobody can guarantee that this or other bugs will not happen anymore.

That's what automatic tests are for....

Mario Vavti

Sat, 11 Sep 2021 08:36:35 +0000

@Malendur yes, unfortunately not everything can be covered with automatic tests at the moment. Huge chunks of the codebase would require a rewrite to make this possible. The situation is gradually improving though...

neue medienordnung plus

Sat, 11 Sep 2021 08:38:37 +0000

@Malendur

That's what automatic tests are for....

Could you describe in a little more detail what you mean by that? Possibly a daemon that goes through the captured ID's and validates them according to certain criteria?

Who is a Hubzilla developer?

neue medienordnung plus

Sat, 11 Sep 2021 11:23:44 +0000 zuletzt bearbeitet: Sat, 11 Sep 2021 12:16:51 +0000

Anyone who contributes to making Hubzilla better is a developer. https://realtime.fyi/help/de/developer/developer_guide

Artikel ansehen

@Mario Vavti Thanks for the explanation.

In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.

This is your opinion that you have solved the problem and answered my questions. The fact that now for 5 days I am forced to invest the time in fixing the bug #bug1608 is in my opinion a proof that the bug is not fixed.

Who is a Hubzilla developer? Should I read this?
Anyone who contributes to making Hubzilla better is a developer.

/help/de/developer/developer_guide
They have joined the Hubzilla project and by doing so they have agreed to live the principles of the project quoted above. I respect your achievement as a programmer. But I also expect you to respect my performance and the performance of other Hubzilla developers who, for example, invest their time to find and fix bugs made by the programmers.

I've actually been planning my time to get on with my Self-Sovereign-Identity project. I assumed that I could rely on the promises published in the Hubzilla description: "cryptographically secured identities that provide authentication independently of the hubs that host them" can be relied upon. PhantomID bug #1608 taught me better and set me back weeks in project development.

@Mario Vavti

@neue medienordnung plus it would be good if you report back on the issue if execution of fhubloc_id_url fixed the issue for you too.

Status on this matter

I have requested my hoster to do the test select * from hubloc where hubloc_id_url = '';. As soon as I have the result, I'll get back to you.
I also asked the owner of the Diaspora account Karsten Meyer, whose account caused the PhantomID #1608 error, that - after I ran the repair tool fhubloc_id_url - he should do something in the conversation "DIE PARTEI" Thread wrote. He did. Unfortunately, I can't comment on whether the PhantomID bug is fixed, since the Diaspora message didn't arrive in my personal stream. I have created a bug report for this message from diaspora not delivered.

I have the impression that even admins who have been involved with Hubzilla longer have not heard about the PhantomID bug and the action like workaround for fixing the bug. I mean the solution approach towards troll that @cb7f604332cf39 brought to the discussion. Under these circumstances, I believe that it is in the interest of the community that the information about bugs as well as bug fixes, workarounds through different channels are sorted and prepared accordingly.

@Mario Vavti

In general it is hard and timeconsuming for developers if a issue report is scattered over X threads and a framagit issue. I kindly ask you to keep the information at one spot. Preferably the framagit issue tracker.

I have deliberately published information in the news through different channels. After all, we agree that opinion posts have no place in a ticket system and will only make the ticket system confusing. I am also of the opinion and I think that this corresponds to the spirit "Contributor Covenant Code of Conduct" and is indispensable for a constructive cooperation that we as developers find space and time for an equal exchange of opinions.

It is also difficult and time-consuming for me as a developer to make progress in problem solving if you as a programmer do not answer my questions at all or answer them incompletely. I mean these questions from the message earlier:

Can someone tell me what is stored in hubloc_id_url?
Maybe a URL to the fediverse ID?
So for example to a diaspora account?

@Mario Vavti

Some hubloc entries were incomplete and therefor a random id was selected. In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.

When you say DB, you mean a database on one node only, right?

Mario Vavti

Sat, 11 Sep 2021 11:45:28 +0000

@neue medienordnung plus

The fact that now for 5 days I am forced to invest the time in fixing the bug #bug1608 is in my opinion a proof that the bug is not fixed.

Seriously?

The hubloc_id_url contains the URL of a channel e.g. https://somedomain.tld/channel/name

neue medienordnung plus

Sun, 12 Sep 2021 02:09:47 +0000

@Mario Vavti With your question "Seriously?" and the missing answer to my question in the comment above 11.09.2021, 11:23:44

@Mario Vavti
Some hubloc entries were incomplete and therefor a random id was selected. In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.
When you say DB, you mean a database on one node only, right?

you give me the impression that you have difficulties to get down from your high horse of the programmer to have the conversation with me - one of many "simple" developers - on eye level. I would be glad if you would answer my question quoted above as a sign that you take me seriously and that I am wrong about my impression.

Mario Vavti

Sun, 12 Sep 2021 03:58:27 +0000

When you say DB, you mean a database on one node only, right?

Basically the DB of every node that updated to version 5 or higher.

Seriously?

Because the amount of time spent collecting data and info does not say anything about if a bug still exists or not. We need to rely on facts and data.

you give me the impression that you have difficulties to get down from your high horse of the programmer to have the conversation with me - one of many "simple" developers - on eye level. I would be glad if you would answer my question quoted above as a sign that you take me seriously and that I am wrong about my impression.

@neue medienordnung plus your impression is your impression and has nothing to do with me. The fact that i answer your questions has also nothing to do with your impression.

In which release notes was the fhubloc_id_url tool announced?

neue medienordnung plus

Sun, 12 Sep 2021 04:41:39 +0000 zuletzt bearbeitet: Sun, 12 Sep 2021 05:27:37 +0000

@Mario Vavti

That is where things went wrong. Some hubloc entries were incomplete and therefor a random id was selected. In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.

Has this bug been mentioned and the repair possibility announced in any release notes? In which release notes, if any, can I find this reference?

Mario Vavti

Sun, 12 Sep 2021 07:50:04 +0000

@neue medienordnung plus in one of the version 5.x releases IIRC.

neue medienordnung plus

Sun, 12 Sep 2021 09:15:59 +0000

@Mario Vavti I did not find the string fhubloc respectively fhubloc_id_url in the releases 5.x. Could be that the bug and fhubloc_id_url tool were not mentioned in any release? Do you have any idea what string I can look for?

Manuel JF

Sun, 12 Sep 2021 10:12:44 +0000

@neue medienordnung plus You're a troll, evidently. Don't you have anything better to do? Sigh

Mario Vavti

Sun, 12 Sep 2021 12:56:50 +0000

@neue medienordnung plus hubloc?

neue medienordnung plus

Sun, 12 Sep 2021 13:05:43 +0000

@Mario Vavti

@neue medienordnung plus in one of the version 5.x releases IIRC.

Do you mean this entry

DB update 1247 to clean up bogus entries in updates
DB update 1246 to mark legacy zot xchans and hublocs deleted

in Release 6.0 https://framagit.org/hubzilla/core/-/releases/6.0 ?

Mario Vavti

Sun, 12 Sep 2021 13:07:38 +0000

@neue medienordnung plus no.

I found these candidates

neue medienordnung plus

Sun, 12 Sep 2021 13:53:36 +0000 zuletzt bearbeitet: Sun, 12 Sep 2021 13:54:46 +0000

It is not clear to me as an administrator when the fhubloc_id_url tool is used. Routinely during the update - e.g. with the release 5.0.7? Or when, as in my example, it is obvious that the database is in need of repair?

Artikel ansehen

@Mario Vavti
I found these candidates

Release 5.0.7
Handle owa with hubloc_id_url only

Release 5.0.6
Fix missing zot hubloc hubloc_id_url when importing a clone

Release 5.0.2
DB update to remove hublocs with no hubloc_hash or no hubloc_callback

Addons
Pubcrawl: do not save actors without an inbox
Diaspora: fix issue with diaspora where hublocs without hubloc_hash were stored

You write

That is where things went wrong. Some hubloc entries were incomplete and therefor a random id was selected. In a DB update we fixed the incomplete hubloc entries and additional the fhubloc_id_url tool was added to be able to apply the fix manually for admins.

It is not clear to me as an administrator when the fhubloc_id_url tool is used. Routinely during the update - e.g. with the release 5.0.7? Or when, as in my example, it is obvious that the database is in need of repair?

Mario Vavti

Sun, 12 Sep 2021 14:19:02 +0000

@neue medienordnung plus under normal circumstances you do not need the fhubloc_id_url tool. The update was applied automatically. But in your case something went wrong obviously. For those cases there is the additional tool as a fallback.

neue medienordnung plus

Sun, 12 Sep 2021 14:39:43 +0000

@Mario Vavti

For those cases there is the additional tool as a fallback.

Do I understand it correctly that until today fhubloc_id_url tool was not mentioned in any release notes?

neue medienordnung plus

Sun, 12 Sep 2021 14:59:12 +0000

@Mario Vavti S. so my finds and questions in the message "I found these candidates" above.

Mario Vavti

Sun, 12 Sep 2021 15:39:09 +0000

@neue medienordnung plus not sure actually, why should it be?

neue medienordnung plus

Sun, 12 Sep 2021 16:34:19 +0000

I'm unsure right now which question your counter question is referring to.

Mario Vavti

Sun, 12 Sep 2021 16:40:58 +0000

@neue medienordnung plus this one: Do I understand it correctly that until today fhubloc_id_url tool was not mentioned in any release notes?

oRx-Qx pirateradio

Sun, 12 Sep 2021 17:40:17 +0000

@neue medienordnung plus I guess you must be a major supporter to speak to the developers like to your obedients. We really appreciate your twelve thousand Euro donation.

neue medienordnung plus

Mon, 13 Sep 2021 06:26:28 +0000

Short answer to your question @Mario Vavti - I am of the opinion that the Hubzilla project is so far that processes and structures in the Hubzilla project are professionalized.

Before judging whether bug # 1608 is worth making such a big splash that labels like #troll or #developerinsulter offender are being handed out, it would be helpful to know what is going on. It would be nice if @hEARt PhoniX, @Marcus Wißmann, @Hilmar Runge, @Oliver, @Mark Nowiasz, who put the effort into administering the Hubzilla welcome hub, reveal:

did you know about the # PhantomID problem before the discussion "Fix the problem of PhantomID's sustainably" [2] started?
Do you wish that you are informed about such a problem, in case another admin, a leading Hubzilla developer: in or also a 0815 Hubzilla user discovers such a problem - or suspects it?
what does the query deliver select * from hubloc where hubloc_id_url = '';- see Mario's query here https://framagit.org/hubzilla/core/-/issues/1608 - on the https://hub.hubzilla.de/ -Hub?
do you wish that you are informed about the workarounds like such a problem that - like current PhantomID problem?
What does this query deliver on top of the hub you maintain?
= List of sources =
[1] FakeIdentity, ChameleonIdentity, IdentityObfuscation, 09/10/2021 - https://framagit.org/hubzilla/core/-/issues/1608
[2] Fix the problem of PhantomID's sustainably, 10.09.2021 - https://zotadel.net/display/b64.aHR0cHM6Ly96b3RhZGVsLm5ldC9hY3Rpdml0eS8xNDgwZTRmNS1lODA3LTQ5ZDktYjk4My02ODU0MTgzM2Y4Mjc

= German Edition =

Abläufe und Strukturen im Hubzilla-Projekt professionalisieren

Kurze Antwort auf deine Frage @Mario Vavti - ich bin der Meinung, dass das Hubzilla-Projekt soweit ist, dass Abläufe und Strukturen im Hubzilla-Projekt professionalisiert werden.

Bevor man beurteilt, ob der Fehler #1608 es Wert ist, solche hohe Wellen zu schlagen, dass Etiketten wie #Troll oder #Entwicklerbeleidiger verteilt werden, wäre hilfreich zu wissen, was Sache ist. Schön wäre, wenn @hEARt PhoniX, @Marcus Wißmann, @Hilmar Runge, @Oliver, @Mark Nowiasz, die sich den Aufwand für die Administration des Hubzilla-Willkommens Hubs aufgebürdet haben, verraten:

hast du vom #PhantomID-Problem gewusst, bevor die Diskussion "Fix the problem of PhantomID's sustainably" [2] gestartet wurde?
wünschst du, dass du über so ein Problem informiert bist, falls ein anderer Admin, ein(e) führende(r) Hubzilla-Entwickler:in oder auch ein 0815-Hubzilla-Nutzer so ein Problem feststellt - oder auch vermutet?
was liefert die Abfrage select * from hubloc where hubloc_id_url = ''; - s. dazu Rückfrage von Mario hier https://framagit.org/hubzilla/core/-/issues/1608 - auf dem https://hub.hubzilla.de/ -Hub?
wünschst du, dass du über die Workarounds wie so ein Problem, dass - wie aktuell PhantomID-Problem - informiert bist?
Was liefert diese Abfrage oben auf dem von dir betreuten Hub?

= Quellenverzeichnis =
[1] FakeIdentity, ChameleonIdentity, IdentityObfuscation, 10.09.2021 - https://framagit.org/hubzilla/core/-/issues/1608
[2] Fix the problem of PhantomID's sustainably, 10.09.2021 - https://zotadel.net/display/b64.aHR0cHM6Ly96b3RhZGVsLm5ldC9hY3Rpdml0eS8xNDgwZTRmNS1lODA3LTQ5ZDktYjk4My02ODU0MTgzM2Y4Mjc

@Hubzilla Support Forum

muppeth

Mon, 13 Sep 2021 09:45:14 +0000

I think what would help this conversation is if you change your tone a little. As @Michal Klodner said. Your accusing tone as if Hubzilla devs are here to screw everyone out does not make anyone look at it serious and also engage with the merrits. So chill, try to be civil and talk to other people with respect they deserve. Noone is here to screw you up nor hide anything from you. Mario is trying to explain you stuff, but it looks like more an interogation done by you then a normal discussion.

If the workaround was not mention in release notes before, it's something that got overlooked or not thought of. You sure have issue with that, so just politely ask for the info to be put in or better yet, update documentation with your finding (add info about what issue is, how it occurs and to use the workaround script to fix it). If issue is more wide-spread and reproducable, one should make ticket on issue tracker and try to work with (and not against) devs to find a proper solution to the problem.

Accusations, guilt seeking and shaming won't get you anywhere imo.

hEARt PhoniX

Mon, 13 Sep 2021 11:11:42 +0000

@neue medienordnung plus I do not know where you get from that hub.hubzilla.de was a "welcome hub". It is an experiment and a hub like any other.

This is from the announcement:

Today we're opening a new hub for the public: hub.hubzilla.de. The hub has been setup like hub.netzgemeinde.eu (including the same, virtual, hardware) but will be administrated in a team.

As the hub has only been installed a few months ago, it is technically wrong to implicitly suggest that it may be affected from a bug that has been introduced and has been resolved long before it has been installed. That feels like asking the shop owner on Easter if there posssibly were any christmas trees left after they had already repurposed that space for easter bunnies. You are comparing things that are not comparable, but by doing so you are raising mistrust.

hub.hubzilla.de has never been an official hub and has never been announced as such
it has been installed after the bug

As for Hubzilla, you have written about this issue, this was :

(...) a bug, because of which the key Hubzilla promise, unique sellingpoint of Hubzilla cryptographically secured identities that provide authentication independently of the hubs which host them end in smoke.

This sounds like a major trust evaporating security breach. In fact the bug was, as I understand it, far from serious. It was just displaying a mix up of post authors and the given account urls. Mind you, this is unpleasant. It is a bug. But is is not such a major and trust eroding security breach you make it out to be.
I would compare it to a real life analogy like this: You have got an access card to for example an hotel room with all the correct information on the RFID chip, just the room number printed wrong on the outside. This RFID chip does determin, whether you have got access, not the number printed on the card. Yes, it is confusing, it is a bug and has to be corrected. But you do not gain access to room 24 while the RFID chip is only configured to let you into room 23.
You asked for and have been given a solution. You have applied the fix and things are fine.
There has even been given a manual check for the database on cli level, to check for any empty value of hubloc_url in the table hubloc. I have proactiveley checked many hubs I administrate, for all there has been no empty hubloc_url.

But you want more information, so please let me do the research for you.
https://framagit.org/hubzilla/core/-/tree/master/spec
Upon reading the specs you will find that everything is determined using certs and signatures. Any display of channel names, hub URLs is just that: a human friendly display. Any access rights, ID determination etc. does happen using certs, signatures, etc: cryptographically secured. If that was not the case, you would not be able to change your channel name, else you would lose all connections and access rights. You would not be able to clone to another hub location, as your url changes and you would lose all connections and access rights etc. All that is determined on a higher level, not human readable account names and URLs. Let alone that identities are relying upon those volatile values. No, your channel has got a certificate assigned, which is linked in the database to your given channel ID, which is again used by the database to find the human readable display name that you have chosen.

Without getting very technical, this is from the documentation available with every Hubzilla installation which is important for background knowlege:
https://framagit.org/hubzilla/core/-/blob/master/doc/database.bb

hubloc xchan location storage, ties a hub location to an xchan
xchan list of known channels in the universe

In other words: hubloc stores information about hub locations.
This corresponds with what you have been told: hubloc_url_id does contain the channel's address.

https://framagit.org/hubzilla/core/-/blob/master/doc/database/db_hubloc.bb
I see that this does not list all tables used today, but it is enough to give you enough information to understand what is going on.
I have made a documentation of all table descriptions so that I can update the doco and upload it. But as mentioned, you have been given the relevant information what hubloc_url_id does by Mario.

To give you an example and confirmation from cli that what you have been told is true, I have checked but obfuscated the result:

MariaDB [hubzilla]> select hubloc_id_url from hubloc ;
+-----------------------------------------------------------------------+
| hubloc_id_url                                                         |
+-----------------------------------------------------------------------+
| http://anyhuburl1.com/channel/channelname1                          |  
| http://anyhuburl2.com/channel/channelname1                          |  
(...)

Which makes clear, why @Mario Vavti has stated that this value must not be empty.

So what happened in the case it has been empty? Upon reading your article and posts and the answers to those, I have understood that hubloc_url_id has been empty in some cases for non-Zot connections and this has caused a wrong display at the conversation frontend, displaying both a wrong display name and displaying a wrong url link to the given profile.

You have been told the hubloc is the primary location, the primary hub for a channel / an ID. That is http://anyhuburl1.com or http://anyhuburl1.com
But we know that Hubzilla does not primarily use that URL to determine access rights, those are there for humans. Actually the hubloc_id is used as a database value to link all the data together: the given certs etc. Relevant for the internal determination are hubloc_guid and so on.
Everything that went wrong was wrongly displaying the name and account URL inside the post. I do not deny that this is important and needs to be fixed. It can cause a lot of confusion and may make Hubzilla look not trustworthy. But that is not true, and I would call it even technically inaccurate. See my hotel room comparison. I will never get to open the door. I may get to see the posters they have applied to their door from the outside for the public to see. I will get confused why I am at their door and not at mine. Yes. But no security breach as such has happened.

MariaDB [zotlabs]> describe hubloc;
+--------------------+------------------+------+-----+---------------------+----------------+
| Field              | Type             | Null | Key | Default             | Extra          |
+--------------------+------------------+------+-----+---------------------+----------------+
| hubloc_id          | int(10) unsigned | NO   | PRI | NULL                | auto_increment |
| hubloc_guid        | char(191)        | NO   | MUL |                     |                |
| hubloc_guid_sig    | text             | NO   |     | NULL                |                |
| hubloc_hash        | char(191)        | NO   | MUL |                     |                |
| hubloc_addr        | char(191)        | NO   | MUL |                     |                |
| hubloc_network     | char(32)         | NO   | MUL |                     |                |
| hubloc_flags       | int(10) unsigned | NO   | MUL | 0                   |                |
| hubloc_status      | int(10) unsigned | NO   | MUL | 0                   |                |
| hubloc_url         | char(191)        | NO   | MUL |                     |                |
| hubloc_url_sig     | text             | NO   |     | NULL                |                |
| hubloc_host        | char(191)        | NO   | MUL |                     |                |
| hubloc_callback    | char(191)        | NO   |     |                     |                |
| hubloc_connect     | char(191)        | NO   | MUL |                     |                |
| hubloc_sitekey     | text             | NO   |     | NULL                |                |
| hubloc_updated     | datetime         | NO   | MUL | 0001-01-01 00:00:00 |                |
| hubloc_connected   | datetime         | NO   | MUL | 0001-01-01 00:00:00 |                |
| hubloc_primary     | tinyint(1)       | NO   | MUL | 0                   |                |
| hubloc_orphancheck | tinyint(1)       | NO   | MUL | 0                   |                |
| hubloc_error       | tinyint(1)       | NO   | MUL | 0                   |                |
| hubloc_deleted     | tinyint(1)       | NO   | MUL | 0                   |                |
| hubloc_id_url      | varchar(191)     | NO   | MUL |                     |                |
| hubloc_site_id     | varchar(191)     | NO   | MUL |                     |                |
+--------------------+------------------+------+-----+---------------------+----------------+
22 rows in set (0.001 sec)

MariaDB [hubzilla]> select * from hubloc where hubloc_id_url = '';
Empty set (0.001 sec)

MariaDB [hubzilla]>

This much for the technical side of things.
Please let us get personal for the time being, as I believe it is important to tell you how I perceived your actions on a very personal level. I do know that you are NOT a troll, that you are NOT intending to bully. But I do understand very much, how your actions can be perceived and understood as such. Which I am very sure is not what you want. I believe you want to further the project, to help and to promote data autonomy, data protection and promote this alternative to corporate solutions.
This is why I do believe you very much need to think hard about your communication style if you want to achieve something. I suspect you may achieve way more with friendly communication than with your current style.

My very first thought upon reading this was: This is a bold claim. It made me angry and not want to deal with the issue anymore, even before fully understanding it. But I knew that would be wrong, so I read the piece and my gut feeling was confirmed: your accusations are far, far away from technically correct.
Unfortunately your further action only made me want to stay far away from this discussion even more, as I have perceived your actions as ... off-putting. My perception was: stay away. I did read enough to get the technical information to understand what was actually going on, as that is what I think is respectful and necessary. I believe that the given information are enough to ease away any seriousness of the issue.

I do very much criticize your actions, which kept me from posting. But I believe that you have the right intention, let me tell you how I personally received your posts:

You posted an article where you jumped to technically incorrect conclusions
By calling this "FakeID" and "CameleonID" you have applied judgemental terms that undermine trust and which I have perceived as very confrontational instead of starting calm and goal oriented communication. This already turned me away from taking your intentions serious and not just bullying. I do know though that you want to achieve the correct thing, but again, you have chosen the very wrong methods. Instead of pulling people in to achieve a common goal, you are turning them away.
By constantly promoting your posts with those judgemental terms you have not made things better.
You accused Hubzilla as insecure and unfit for the purpose to provide you with a secure ID
You posted the same issue again and again
You did not listen to what you have been told
You did not read the available help and have not tried to get to a technical foundation to what has actually been going on and to understand what you have actually accused the project and it's devs of

And by the way:
I have written many posts and not posted them as I did not want to fuel the fire and was not able to do the research at the time to explain things properly. All in all I have spent a full working day (!) just writing answers to you.

I do question if this is really in proportion the the initial bug.

Please, I do know that you want to achieve good and right things and do support Hubzilla, please do understand but you have not supported Hubzilla here but on the contrary. We do have very limited resources. And even writing this post alone has taken me about four hours as I do neither want to hurt you, nor provide false information.

Big Bang for bug #1608 research

neue medienordnung plus

Mon, 13 Sep 2021 16:55:16 +0000 zuletzt bearbeitet: Tue, 14 Sep 2021 17:24:52 +0000

= German formatted original - s. bottom =

Thank you @hEARt PhoniX,

your opinion, your appeal and rectification mean a lot to me. I'll be brief and get personal too. I made a conscious decision not to contact you directly and did not ask you to comment on bug # 1608. Although there is a good reason for it. You do the technical administration of my hub https://realtime.fyi/ - Hubzilla installation, updates, etc. - thank you again for that.

I did not ask you to comment because:
- I didn't know whether you had recovered from the Corona
- I know that, like all of us, you have no time to spare
- But mainly I have not asked you for a statement, as I have confidence in your ability as an administrator and therefore I still assume that the PhantomID error was not caused by your doing or not doing it, but by:
- error in the design of ZOT protocol?
- incorrect implementation of the Zot concept in the program code?
- other causes ...?
Warning - I get very personal here! You could save yourself the long abstract explanations on the technical details. Instead, I would like to hear from you a compact explanation of what is, what could be the reason that the error # 1608 occurred on the web space administered by you, the hub that you (technically) administrated.

Now Mario asks me whether the error arose before the installation of Hubzilla 6.2 or afterwards. When did you install version 6.2? In the meantime, I have already created logs with time stamps for the PhantomID's posts when communicating with those affected from the Diaspora network. And I can't get the debugging file on the https://realtime.fyi/ -Webspace that Mario needs to find the cause of the error "message from diaspora not delivered # 1609" https://framagit.org/hubzilla/core/-/issues/1609 to determine. I asked you by direct message @hEARt PhoniX:

- on 09/11/2021 in the sql console this query
select * from hubloc where hubloc_id_url = '';
for the hub's database https://realtime.fyi/ perform
- on 09/11/2021: "Can you make a binding statement in connection with the PhantomID bug # 1608 issue" the updates since 4.6 were executed correctly, like described in the release notes "?"
- today the log file Log123.log from to https://realtime.fyi/ . Mario needs this to determine the cause of the "message from diaspora not delivered # 1609" error
FYI: Admittedly, the FantomID mistake made me noticeably stressed, stressed, probably thin-skinned and less considerate than usual.
1) First - this is my perception - the # 1608 is causing cracks in my virtual Hubzilla home, which I have been building for 5 years in detail.
2) Then I was confronted with the frustration of those affected, the diaspora users, and for these people I served as a lightning rod for the uncertainty and frustration caused by Error # 1608. For bug # 1608, for which I can't help. A Diaspora user, himself a programmer, said "What shit. ... If something like that happens, I consider the whole Fediverse to be broken and unusable. " - Original sound. The person owes this perception to error # 1608.
3) Ah yes, the 5 days in which I spent a lot of time researching error # 1608, I actually planned for my "Self-Sovereign-Identity" project, which is based on Hubzilla guaranteeing robust, bomb-proof authentication. The project is paused for now until I can be certain that the likelihood of error # 1608 occurring in Hubiverse is vanishingly small.
= Source =
[1] Big Bang for my research for error # 1608 is here - https://huby.infozoo.de/item/a6d1d8bb-7457-4c81-84fc-fb2ee9d127f0
Big Bang , because I noticed that @ RockyIII refers to @Hartmut Noack, which was incomprehensible to me because instead of @Hartmut Noack shows me Hubzilla in my personal stream to this day misterious "@ Ninah Pixie ☥ ". I still find the topic of the conversation in [1] exciting to this day and I will come back to it as soon as the topic of error # 1608 subsides. But I was not allowed to relax and follow the thread of the conversation, because this thread was and is still arbitrarily through @ Ninah Pixie ☥ "and" @ Ditje"separated. Obviously, this big bang is so literally explosive that it threw my mind noticeably off balance.

= German formatted original =

Urknall für die bug #1608 Recherche

Danke @hEARt PhoniX,

deine Stellungnahme, dein Appel und Richtigstellung bedeuten sehr viel für mich. Ich fasse mich kurz und werde auch persönlich. Ich habe bewusst darauf verzichtet, dich direkt zu kontaktieren und ich habe dich nicht um eine Stellungnahme zum Fehler #1608 gebeten. Obwohl es einen guten Grund dafür gibt. Du machst technische Administration meines Hubs https://realtime.fyi/ - Hubzilla-Installation, Updates usw. - danke dir nochmal dafür.

Ich habe dich nicht um eine Stellungnahme gebeten, weil:

ich wusste nicht, ob du von der Corona dich erholt hast
ich weiß, dass auch sonst - wie wir alle - du keine Zeit übrig hast
aber hauptsächlich habe ich dich nicht um eine Stellungnahme gebeten, da ich Vertrauen habe in dein Können als Administrator und deswegen gehe ich nach wie vor davon aus, dass der PhantomID-Fehler nicht durch dein Tun oder Lassen entstanden ist, sondern durch:
- Fehler in der Konzeption des Zot Protokols?
- fehlerhafte Umsetzung des Konzepts von Zot Protokol im Programmcode?
- andere Ursachen ...?

Achtung - hier werde ich sehr persönlich! Du könntest dir die lange abstrakte Ausführungen zu den technischen Details sparen. Stattdessen würde ich gern eine kompakte Erklärung von dir hören, was ist, was könnte der Grund sein, dass auf dem von dir administrierten Webspace, von dir (technisch) administrierten Hub der Fehler #1608 vorgekommen ist.

Jetzt fragt mich Mario, ob der Fehler vor der Installation von Hubzilla 6.2 entstanden ist oder danach. Wann hast du die Version 6.2 installiert? Zu den Posts der PhantomID's habe ich inzwischen bei der Kommunikation mit Betroffenen aus dem Diaspora-Netzwerk bereits Protokolle mit Zeitstempeln erstellt. Und ich komme nicht an die Debugging-Datei auf dem https://realtime.fyi/ -Webspace, die Mario braucht, um die Ursache für den Fehler "message from diaspora not delivered #1609" https://framagit.org/hubzilla/core/-/issues/1609 zu ermitteln. Ich habe dich per Direktnachricht gebeten, @hEARt PhoniX:

am 11.09.2021 in der sql-Konsole diese Abfrage
select * from hubloc where hubloc_id_url = '';
für die Datenbank des Hubs https://realtime.fyi/ durchzuführen
am 11.09.2021 Stellung zu nehmen: "Kannst du im Zusammenhang mit dem Thema PhantomID-Bug #1608 vlt. verbindliche Aussage machen "the updates since 4.6 were executed correctly, like described in the release notes"?"
heute die Logdatei Log123.log von https://realtime.fyi/ zu schicken. Diese braucht Mario, um die Ursache für den Fehler "message from diaspora not delivered #1609" zu ermitteln

FYI: Zugegeben, der Fehler FantomID hat mich spürbar mitgenommen, gestresst, wahrscheinlich dünnhäutig und weniger rücksichstvoll als sonst gemacht.

Erstens - so ist meine Wahrnehmung - sorgt der #1608 für Risse in meinem virtuellen Hubzilla-Heim, das ich seit 5 Jahren in Kleinarbeit baue.
Dann wurde ich mit dem Frust der Betroffener, der Diaspora-Anwender konfrontiert und diente für diese Menschen als Blitzableiter für den durch Fehler #1608 verursachte Unsicherheit und Frust. Für den Fehler #1608, für den ich nichts kann. Ein Diaspora-User, selbst Programmierer, sagte "Was für eine Scheiße. ... Wenn sowas passiert, betrachte ich das ganze Fediverse als kaputt und unbrauchbar." - O-Ton. Diese Wahrnehmung verdankt die Person dem Fehler #1608.
Ah ja, die 5 Tagen, in den ich viel Zeit mit den Recherchen rundum Fehler #1608 verbracht habe, habe ich eigentlich für mein Projekt "Self-Sovereign-Identity" eingeplant, das darauf baut, dass Hubzilla robuste, bombensichere Authentifizierung gewährleistet. Das Projekt pausiert erstmal, bis ich Gewissheit habe, dass die Wahrscheinlichkeit, dass in Hubiverse Fehler #1608 passiert, verschwindend gering ist.

= Quelle =
[1] Urknall für meine Recherchen für den Fehler #1608 ist hier - https://huby.infozoo.de/item/a6d1d8bb-7457-4c81-84fc-fb2ee9d127f0
Urknall, weil mir aufgefallen ist, dass @RockyIII auf @Hartmut Noack verweist, was für mich unverständlich war, weil statt @Hartmut Noack zeigt mir Hubzilla in meinem persönliche Stream bis heute misteriöse "@Ninah Pixie ☥". Das Thema der Unterhaltung in [1] finde ich bis heute spannend und ich komme noch darauf zurück, sobald das Thema Fehler #1608 sich legt. Aber es war mir nicht gegönt, den Faden der Unterhaltung entspannt zu verfolgen, weil dieser Faden wurde und wird immer noch willkürlich durch @Ninah Pixie ☥" und "@Ditje" getrennt. Dieser Urknall hat offensichtlich derart buchstäblich Sprengkraft, dass er mein Gemüt spürbar aus dem Gleichgewicht brachte.

hEARt PhoniX

Mon, 13 Sep 2021 19:38:32 +0000 zuletzt bearbeitet: Mon, 13 Sep 2021 22:19:37 +0000

@neue medienordnung plus
I have seen no direct message from you. It may be possible that your hub has given up delivery as my hub was faulty on Saturday and I noticed that late. Yes, that is how incompetent I am as an admin. I had turned off monitoring for my own server the day before during some work.

Also, rest assured, in order to protect your privacy I collect as little log files as possible with all my hubs. As you have enabled logging for your hub, you are able to analyze them and provide Mario with the requested data. /admin/logs/ There you are able to select only the bits required in order to collect and use as little data as possible, as the fairness to your visitors and the law requires and to assist Mario with doing as much work as possible and giving him only that lines he really needs to see.

Furthermore I can assure you that you have seen the result of the SQL select from your hub in the post above.

Then:
Where do you get from I have Corona?
You are jumping on to conclusions yet again. Unfortunately those are based on half-truths, at best. I have never, ever said I do have Corona because I have not had it.

And here is yet another problem:

But mainly I have not asked you for a statement, as I have confidence in your ability as an administrator and therefore I still assume that the PhantomID error was not caused by your doing or not doing it, but by:
Error in the design of the solution
incorrect implementation of the concept in the program code
other causes ...?

See, you did it again. You are jumping onto conclusions based upon what you are thinking or want to think. I cannot promise I did not make a mistake, I am human. I even cannot deny making a mistake or what possibly made me believe I did not make a mistake, as it is way too long ago.
But: You are the admin of your hub, therefore it is your task to check the hub's functionality after each update, including the database. That is something I cannot do for you.
/admin/dbsync/ Have you done that? That is the place where you will get information about update errors.
You are responsible for your hub. Not me. I have got no access, and you know that.

I am sorry, but as you have read my post above, you will know how often I had to correct you.
This has continued with your answer post.
In addition you are choosing an extremely over-dramatic language. FakeID. BigBang. Goes up in smoke. I acknowledge that this seems to be your style. Though I would like to ask you to take a step back and have look how that may harm your actual intent. I believe that this is not professional, calm and balanced (respectful?) communication.

I am sorry you have been targeted by frustrations from other people, and I do understand that this has caused you stress. You say that your finding of that bug has caused your trust into Hubzilla going up in smoke. No, Hubzilla's claim into being trustworthy has gone up in smoke. Though, I do ask you what have you done to regain that trust?
There is an established professional way to deal with such things:

Stay
calm
and
inform the developers
(and listen to them,
work together to develop the best strategy out)

What you have done was stirring up as many people as possible, demanding answers from people who had no idea what was going on, writing a burning article about how your trust is evaporating, wrote to devs from other systems before first making sure the problem was with them and not with Hubzilla and so on. That means: stirring up as much dirt as possible instead of following the established IT way.

You demand professionalism from @Mario Vavti, but what you have done was running around like a headless chicken, stirring as many people up as possible and sowing mistrust along the way inside as many people as you could reach.
I am sorry if I do not get the full chronology 100% right, but, this is what I perceived. But I hope it may help you to see the problem. The established and professional way if you find a security issue issue is: stay calm. Analyze. Determine where the problem lies. Do not stir up others. Tell development, the correct system's development, not any possible developmwnt. Listen to development. If it really is a serious issue have it fixed and then work together on a strategy how to communicate it.
Unfortunately, just as I have stated in my first post, you have sawed mistrust and confusion and caused a lot of frustration. The damage is done, you have actively sawn mistrust in the fediverse. You have obviously not just hurt Hubzilla, bullied it's main dev (where I believe an apology would be on order), but you have sawn mistrust in the fediverse. Wow.
Such things are hard, if not impossible to repair.
I am very sorry, but that is now my point of view on the whole issue.

You have bullied @Mario Vavti and your wording was implicitly and directly accusing him of being nontransparent, incompetent, unwilling to prioritize your question that he had already answered. And solved.

I have typed several responses. I felt it was a necessity to support @Mario Vavti who is investing a lot of his time and energy to advance the very project you have been attacking, and yes, I feel you have attacked him. This is not a way forward and I do hope you may understand how damaging on many sides your behavior has been - and to apologize to Mario.

I have learned the hard way: If I am angered and shocked by something and notice that I am not able to think straight, I try to force myself to take a step back. Be it just a deep breath, going to the toilet, having a cuppa, or returning tomorrow. That depends upon the urgency and certainly if there are lives in danger. First rule: try to stay calm. Do not post in anger or panic.

And just on a side note:
This post has cost me about two hours. That means six hours work, just today.
I had intended to prepare Hubzilla promotion today.
And I am not writing this to make you feel bad, I do know you have invested a lot of energy as well despite wanting to do something else. I am a slow writer. I try to balance my words. But I do want to show you the consequences of your actions and your communication style. People need to tend to you and your demands, invest time and this time cannot get invested into the project as such.
And now think of that my work for the project is quite insignificant compared to @Mario Vavti's. Had he spent a day to write to you, he would have to spend days writing to others.
I think that we all agree that we expect him to write code.
I would even go further and say: I expect him to be happy and to enjoy working for us as much as possible. And that does include not writing code, but playing the trombone. Or having a life.
And it is our task not to spoil it for him.

astabski

Tue, 14 Sep 2021 01:42:40 +0000

@hEARt PhoniX

I don't like your punch line in this discussion (it's actually a row, not a matter-of-fact discussion). I hesitated to speak, because I had suspended my participation in the Hubzilla project for the time being, among others for reasons mentioned by @neue medienordnung plus. But for the sake of Hubzilla, I decided to write something. I think this discussion cannot be end at this point by stating that @neue medienordnung plus is an over-demanding guy who sticks to insignificant details. He said bluntly, "The king is naked," making a few important points.

Firstly. Are you sure the reported issue # 1608, confirmed by @neue medienordnung plus, is a "fixed" bug? Perhaps the problem is deeper and should not it be dismissed? If memory serves me correctly, @mike has already spoken about problems of the communication of Hubzilla with Diaspora, stating that it cannot work well and that is why he resigned from support Diaspora in the Zaps.

Secondly. The Hubzilla platform is functionally "overcombined", and too complicated, deviating from the modern direction of web application development. A lot of functionality is promised here, but many of them don't work well or are useless. There is no good, up-to-date documentation.

Thirdly. In the discussion talks about a "hard-working development team". I noticed that for a long time only @Mario Vavti has been creating all important code changes in the repository. He is the lead developer (and the only developer, I think). It is he who has the vision and roadmap of the project in his head. It races with the versions ahead, and bugs multiply like real bedbugs. Certainly @Mario Vavti is doing a heroic job, but he will not be able to maintain the developing of a contemporary social platform alone. The current direction of Hubzill's development is, in my opinion, a dead end. I think it would be good for @Mario Vavti to revise the way the project is managed, start a discussion about it and get developers capable of solving existing problems.

Finally, the Hubzilla participants should ask themselves if they want to create either a brand or a well-functioning OpenSource social platform. In the latter case, any criticism is admissible and necessary, if it is constructive.

That's it.

mike

Tue, 14 Sep 2021 05:46:41 +0000

We appear to have a wildly different definition of constructive criticism. This looks to me more like toxic sludge. And it smells just like like toxic sludge.

So any results of that SQL query? Are the empty hubloc_id_url's gone? Any appearance of the reported issue since the empty hubloc_id_url's were fixed? Anywhere? These shouldn't be difficult or contentious questions.

Mario is adult

neue medienordnung plus

Tue, 14 Sep 2021 05:59:26 +0000 zuletzt bearbeitet: Tue, 14 Sep 2021 17:15:06 +0000

= German formatted original - see bottom =

@hEARt PhoniX @Andrzej Budziński thank you!

I have given this text the non-technical, but from my point of view factual heading "Mario is adult" because some emotional and - in my opinion - not very factual statements seem to arise are based on the assumption "@Mario Vavti is in need of protection" and this strongly suggests the message "@Mario Vavti is in need of protection" . From my point of view, @Mario Vavtihas shown convincingly that he can deal confidently with points of view that are not his points of view. I mean

@neue medienordnung plus your impression is your impression and has nothing to do with me. The fact that i answer your questions has also nothing to do with your impression.

https://hub.somaton.com/item/a44c9cd3-b429-46d1-94b4-62d569d4a406

Encouraged by the assumption "Mario is in need of protection", the commentators seem to feel entitled to distribute labels like # Troll or # Developer offender, which - my opinion is neither factual nor to correct error # 1608 - Caution! - that's the topic in this thread - can contribute.

It is a mystery to me why some people in the Hubzilla community seem to take it for granted that a questioner has to answer the questions of a leading programmer in the project and when the same questioner tries to answer the leading programmer or simply To get feedback on factual questions about the bug or about a release note is interpreted as a "libel of majesty".

= German formatted original =

@hEARt PhoniX @Andrzej Budziński - Danke!

ich habe diesem Text mit der nicht technischen, aber aus meiner Sicht sachlichen Überschrift "Mario is erwachsen" versehen, weil einige emotionalen und - meine Meinung - wenig sachliche Stellungnahmen scheinbar auf der Annahme beruhen "@Mario Vavti ist schutzbedürftig" und dadurch eindringlich die Botschaft suggeriert wird "Mario ist schutzbedürftig". @Mario Vavti hat aus meiner Sicht überzeugend dargestellt, dass er mit den Standpunkten, die nicht seine Standpunkte sind, souverän umgehen kann. Ich meine

@neue medienordnung plus your impression is your impression and has nothing to do with me. The fact that i answer your questions has also nothing to do with your impression.

https://hub.somaton.com/item/a44c9cd3-b429-46d1-94b4-62d569d4a406

Bestärkt auf der Annahme "Mario ist schutzbedürftig" fühlen sich die Kommentatoren scheinbar berechtigt Etiketten wie #Troll oder #Entwicklerbeleidiger zu verteilen, was - meine Meinung - weder sachlich ist noch zur Behebung des Fehlers #1608 - Achtung! - das ist das Thema in diesem Thread - beitragen kann.

Es ist für mich ein Rätsel, warum es von manchen Mitmenschen im Umfeld der Hubzilla-Community scheinbar als selbstverständlich angenommen wird, dass ein Fragesteller die Rückfragen eines führenden Programmierers im Projekt brav zu beantworten hat und wenn der gleiche Fragesteller versucht vom führenden Programmierer Antworten oder einfach eine Rückmeldung auf sachliche Fragen zum Fehler oder zu einem Release Notes zu bekommen, wird es als "Majestätsbeleidigung" interpretiert.

Rasenmäher-Roboter vs. kopfloser Huhn

neue medienordnung plus

Wed, 15 Sep 2021 05:46:47 +0000 zuletzt bearbeitet: Fri, 17 Sep 2021 05:39:00 +0000

@hEARt PhoniX ich habe hier - s. unten - eine unvollständige Chronologie veröffentlicht, die meiner Erachtens deine These mit dem kopflosen Huhn wiederlegt. Ich habe Daten gesammelt, ich habe versucht im Hintergrund, nicht öffentlich die Situation zu bereinigen.

Zusätzlich zu den Unsicherheiten, die der Fehler #1608 für mich persönlich verursacht hat. haben mindestens zwei weitere Hubzilla-Besonderheiten, Features dafür gesorgt, dass die Situation so sich entwickelt hat, wie diese sich entwickelt hat. Diese Besonderheiten sind:

ich habe es so verstanden, dass Mario Vavti meine Articel-Nachricht sieht - s. https://framagit.org/hubzilla/core/-/issues/1607 . Die Nachricht hat Mario aber erst gelesen, als ich ihn separat kontaktiert habe
meine Nachrichten an dich, @hEARt PhoniX sind nur deswegen nicht angekommen, weil du dein System gewartet hast. Hier meine ich besteht ein Handlungsbedarf bei der Hubzilla-Entwicklung auf konzeptioneller Ebene, wie man für eine unterbrechungsfreie Kommunikation unabhängig von Wartungsarbeiten sorgen kann

Was dein Vergleich mit dem kopflosen Huhn angeht. Hier schließe ich mich dem Standpunkt von @Mario Vavti an - das ist deine Wahrnehmung der Ereignisse.

your impression is your impression and has nothing to do with me. The fact that i answer your questions has also nothing to do with your impression.

https://hub.somaton.com/item/a44c9cd3-b429-46d1-94b4-62d569d4a406

Ich selbst würde mich im Vorfeld der Öffentlichmachen des Fehlers #1608 mit einem Rasenmäher-Roboter vergleichen, der - zugegeben - ohne viel Verstand, dafür aber mit viel Geduld , Hartnäckigkeit versucht hat das richtige zu tun, um die Situation geräuschlos zu deeskalieren. Das dabei der Rasenmäher evtl. auf ein Explosionsgemisch gestossen hat - sowas kann passieren.

Update 2021-09-15
es war keine gute Idee, den Screenshot in dieser Version Online zu stellen. Ich habe ihn entfernt - danke @hEARt PhoniX.
#RasenmäherRoboter

hEARt PhoniX

Wed, 15 Sep 2021 08:26:02 +0000

I believe we have a significantly different understanding of ... kind of everything, but especially to facts, what they are and how to get there. Your post above does yet again show me that.
I believe I have corrected you so often where you jumped to conclusions based upon what you wanted to think and / or half truths and you may possibly (my point ov view) be recommended to reevaluate your strategy on how to get people to work together. I do not think your approach does live up to what you demand from others, to communicate in a friendly, respectful, goal oriented and professional way. This is unfortunate, as I still believe we do have a lot in common in that we want to give people the best possible chace to reclaim their online privacy and control over their data. But it needs to be acknowledged.
Therefore I bow out of this discussion.

As you brought up one quote twice, I would like to add the context in which it occured.

https://hub.somaton.com/item/a44c9cd3-b429-46d1-94b4-62d569d4a406
you give me the impression that you have difficulties to get down from your high horse of the programmer to have the conversation with me - one of many "simple" developers - on eye level. I would be glad if you would answer my question quoted above as a sign that you take me seriously and that I am wrong about my impression.

@neue medienordnung plus your impression is your impression and has nothing to do with me. The fact that i answer your questions has also nothing to do with your impression.

Oliver

Wed, 15 Sep 2021 13:04:43 +0000

I was mentioned here a few days ago, but unfortunately only noticed it today, as the initiator of this discussion has been on my blocklist for a long time (which I briefly deactivated for other reasons).
I can't follow the discussion here from a technical point of view, it's too confusing for me. And I don't want to add anything to this discussion, as it's obviously a complete waste of time. The initiator of the post is possibly with good intentions, but unfortunately completely resistant to learning and unable to read other posts. Superblock is now active again.