emaxmax

emaxmax@hub.netzgemeinde.eu

Hubzilla account of @max@ntwk.tk

Change album name

emaxmax

Mon, 01 Jun 2020 15:06:37 +0200

Hello !Hubzilla Support Forum & !Hubzilla Users Support

Is there a way to change the name of a picture album (with no impact on IDs and URLs of its images)?

Thanks

show all 6 comments

Haakon Meland Eriksen (Parlementum)

Tue, 02 Jun 2020 07:23:22 +0200

Then I do not know what is wrong, I tested it on my end before answering. Which version do you see on /siteinfo ?

emaxmax

Tue, 02 Jun 2020 10:18:19 +0200

@Haakon Meland Eriksen (Parlementum): 4.6

@Mike Macgirvin: seems to work. I'll do more tests. Thanks

emaxmax

Sat, 06 Jun 2020 16:27:28 +0200

@Mike Macgirvin, I confirm after some more tests (including sync between channels): WebDAV renaming works.

Test tags and mentions

emaxmax

Mon, 11 May 2020 15:35:32 +0200

#Hubzilla #ActivityPub #Hashtags #Mentions
@Malendur @Mike Macgirvin @Mario Vavti
!Hubzilla Support Forum @hubzilla help
Trying some hashtags and mentions.

emaxmax a publié une nouvelle photo pour 2020-05

Hubzilla, Socialhome and primary channel

emaxmax

Thu, 21 Nov 2019 12:32:38 +0100

Hello !Zotlabs|Hubzilla Development, !Zotlabs|Hubzilla and !Hubzilla Support Forum

I found a strange bug between #Hubzilla and #SocialHome but I would appreciate some analysis before opening issues.

Testcase :
https://dacha.xmpp.moe/channel/caranistar is an Hubzilla channel.
It’s replicated on https://eattherich.social/channel/caranistar
https://dacha.xmpp.moe/channel/caranistar is the primary channel.

On SocialHome, https://dacha.xmpp.moe/channel/caranistar is added as a contact and followed.
Here is his profile, seen by #SocialHome :
https://socialhome.network/p/06b9c4a7-c840-468f-a4c7-49d0e1deeac8/

The weird thing appears when Caranistar posts an image on his main account.
On other Hubzilla account following Caranistar, the image is correctly linked to the main account.
But on #Socialhome, the link in the post points to the backup account (as you can see by yourself on the profile page).

Where could be the bug ?

Ping @jaywink@friendica.feneas.org and @Socialhome HQ

show all 23 comments

Mario Vavti

Thu, 21 Nov 2019 13:38:34 +0100

It has already been said many times: channel cloning and federation with non nomadic networks is not compatible...

Giacomino

Fri, 22 Nov 2019 19:13:47 +0100

"channel cloning and federation with non nomadic networks is not compatible"
is our mantra

Max Kostikov

Fri, 22 Nov 2019 19:15:36 +0100

@Giacomino In new release some improvements in this part of code will arrive but in common, yes, we can not to do much in this direction outside Zot.

ayla

Sat, 23 Nov 2019 00:37:22 +0100 from ActivityPub

Ping @jaywink@jasonrobinson.me

Max Kostikov

Tue, 26 Nov 2019 09:36:16 +0100

@Socialhome HQ
Hubzilla delivers post from location where is was created so you are right.

emaxmax

Tue, 26 Nov 2019 09:49:01 +0100

So if a user has a primary account and 3 cloned ones, each time he posts on his primary account, Diaspora* networks (including #SocialHome) will recieve and archive 4 copies of the same post?

(ping @Caranistar)

Max Kostikov

Tue, 26 Nov 2019 09:57:04 +0100

@emaxmax

So if a user has a primary account and 3 cloned ones, each time he posts on his primary account, Diaspora* networks (including #SocialHome) will recieve and archive 4 copies of the same post?

No, only one.

emaxmax

Tue, 26 Nov 2019 10:01:42 +0100

Which one?

Max Kostikov

Tue, 26 Nov 2019 10:06:59 +0100 last edited: Tue, 26 Nov 2019 10:07:20 +0100

@emaxmax

Which one?

As I wrote above, the one where post was created.
BTW you have ability to send and recieve post from and to Diaspora / ActivityPub networks contact from any Hubzilla clonned channel location in case if you added this contact in every clone. At D* / AP side for clonned channel with 2 locations it will looks like two separate contacts with different addresses.
In upcoming Hubzilla release will arrive some improvements to handle this.

Caranistar

Tue, 26 Nov 2019 10:29:15 +0100

@Socialhome HQ, @Max Kostikov
I confirm I wrote the post recieved on https://socialhome.network/content/4978204/nephiraim-ltdiv-classwall-item-footerg/ from my primary account (not the one shown on #SocialHome ).
Yet, the link is from a cloned account.

Max Kostikov

Tue, 26 Nov 2019 11:18:30 +0100

@Caranistar Yes, the address of author of the top post indicates the location of the primary Hubzilla channel, but in comments real source are shown.

Caranistar

Wed, 27 Nov 2019 01:11:16 +0100

That means that my primary account sent a message to #SocialHome with a link to a cloned account. That sounds like a #Hubzilla bug...

Max Kostikov

Wed, 27 Nov 2019 09:06:32 +0100

@Caranistar

That means that my primary account sent a message to #SocialHome with a link to a cloned account. That sounds like a #Hubzilla bug...

If you are sure please open issue in Hubzilla tracker with additional details.

Giacomino

Sat, 30 Nov 2019 16:42:19 +0100

about the clones, let me tell you a story:
we say that the main channel of mister x is on the hub "x" and the clone in hub "y", in diaspora, apparently without logic what happens?
Mister x placed a post in his main channel in "x" but in diaspora appears posted by mister x in "y" .
So, as we can deduce in this case, we say that: either the person follows all of us (both principal and clones), or the person always ends up losing something.
I have been using clones for years and this bizarre behavior appears every now and again: a post is posted by the main channel but sometimes it comes from the clone on diaspora, then, as if by magic, everything returns to normal....

Today happened again.

Caranistar

Sun, 01 Dec 2019 00:22:03 +0100

Great: I'm asked to create an issue and it's closed with no more investigation....

emaxmax

Sun, 01 Dec 2019 02:44:37 +0100

And with fallacious justifications...

M. Dent

Sun, 01 Dec 2019 05:57:46 +0100 last edited: Sun, 01 Dec 2019 05:55:37 +0100

@Caranistar  - I'm just another volunteer dev trying to lend a hand where I can and contribute back to some awesome software, but I'm still sorry that happened that way.  I can definitely see where it would feel like you were getting mixed messages.  Ultimately, you were.

I don't think there was any disrespect intended. I think you just ran into one of the problems with fully "decentralized" / "distributed" systems.  Don't get me wrong, the devs do a lot of collaboration and cooperation - - but not on everything.  And sometimes things like this happen because of it.

In this case, it appears that one dev found your problem interesting and, I'm supposing, asked you to put in a bug report anticipating that he would be the one most likely to look into it. The dev who asked you to submit it  happens to be a dev who has done a phenomenal job at trying to clear things from the issues list in recent months.

In the mean time, another dev, who had already mentioned in this thread that your configuration is not supported, was going through and reading bug reports and saw what appeared to be a duplicate report concerning a problem unsupported configuration.

If he hasn't been following all the updates on this thread, there was no way for the dev who closed the issue to know you were requested to submit the issue by another dev.  (Thus, the problem with distributed systems.)

Again, I don't believe that there was any intention at disrespect - just two autonomous individuals acting on the information they had available to them at the time.

As for the legitimacy of the justification - from a technical standpoint, I will admit that I also find the situation you describe interesting - and I would be very interested in figuring out "why?"  But for me, it would only be to answer the idle curiosity - and while like every one of the devs on this project, I love helping out others, I also have far more pressing matters to work on and I have no direct need to solve the problem other than to satisfy my curiosity.

In addition to that, I do know that there are very good reasons that the attempted configuration is "unsupported."

A massive amount of effort has been expended over the years attempting to resolve things that have presented themselves as apparently simple issues but proved to be exceedingly difficult and complex and ultimately unsolvable when working with cloned channels on non-nomadic networks.

Those who have been around the longest contributed a lot to try to resolve those issues have learned that the best way to avoid wasting time is to acknowledge that fact - and maintain a fairly hard and fast rule regarding unsupported configurations.  Consider that they simply have been burned far too many times.

The justification is not fallacious, it's true.  It's an unsupported configuration - and for very good reasons.

in addition to being true, that answer is also an attempt at setting expectations appropriately.  It's sort of like saying, "Based on experience with issues like this in the past, even if devs spent the next few weeks trying to figure this out, it is likely, based on experience, that we will be in the same place that we are and no closer to a fix.  Better to frustrate you now and tell you it won't get fixed than to build up your hopes." (That doesn't mean it is actually unsolvable - but experience has taught that it's better to let sleeping dogs lie - there's plenty of other work to be done and dealing with such issues has proved to have very, very, very little return on investment.)

With all of that in mind, without communication from other devs or at least the knowledge that another dev asked for the submission, issues like this tend to get officially "closed" with what is a seemingly "pat" answer.

It's important to note that doesn't mean it will never be addressed or that the issue report is useless.  Sometimes good reports have a way of resurfacing during other work and even sometimes in such a way that the reported problem is also resolved in the midst of other work.  But that isn't a guarantee.

Anyway - hopefully that at least provides some insight.

I know it doesn't help the stinging feeling - but sometimes it's helpful to know that it wasn't intentional or capricious.  Believe me, everyone around here would love to be able to have reliable interactions between cloned channels and non-nomadic networks.  But after slamming your head against a wall so many times that the grey matter starts oozing from the wound, there comes a point at which you have to admit it's better to stop banging your head against the wall.

Mario Vavti

Sun, 01 Dec 2019 09:11:11 +0100

@Caranistar i am sorry. I did not follow this thread and did not see that you were asked by @Max Kostikov to open an issue.

I will reopen the issue. The comment i made is still valid though.

emaxmax

Mon, 02 Dec 2019 09:46:31 +0100

Whereas I understand that nomadic identities present incompatilities with non-nomadic contacts, it's harder to figure out why cloned channels send messages to a D* relay.

M. Dent

Mon, 02 Dec 2019 16:05:53 +0100 last edited: Mon, 02 Dec 2019 16:03:40 +0100

I'm pretty sure it has to do with nomadic synchronization and some of the failsafes that have been put in to maintain reliable message delivery.

It isn't as simple as, "the software is misbehaving." There are a number of underlying delivery mechanics that are under review as we move toward Zot-6.  Suffice it to say, "reasons."  In most cases, the software is behaving as it needs to so that it can deal with the unreliability and various different circumstances that happen on the Internet as a whole (latency, overloading of resources on a given hub, various other delays that can happen with IP routing, etc.).

On a message delivery network, message delivery is the important thing.  On a distributed message delivery network over a generally but not perfectly reliable and predictable transport network, fail safes and backup systems need to be put into place.  What you are seeing is likely an artifact of that.

M. Dent

Mon, 02 Dec 2019 16:15:17 +0100 last edited: Mon, 02 Dec 2019 16:13:00 +0100

To be honest, when I started playing around with the project a couple years ago, I saw some of the things you are seeing and thought to myself, "That doesn't make sense." But as I dug into the message delivery mechanics and WHY they are what they are, it became more clear. Suffice it to say, you're on a well-worn path.

Even though we know of them in a general sense, it's good for some of us to be reminded that these issues are still "out there" with some concrete examples as you provide.

Unfortunately, it looks like, just as we did when GitHub was taken over by Micro$oft, we are looking at another move for the repository (as well as the issue database) sometime in the coming months as FramaSoft announced their decommissioning of FramaGit. This fact also contributes to a desire to keep the number of open issues down, just in case they need to be manually migrated to a new platform). Hopefully, maybe, we can at least move the Issue database onto our own infrastructure by then and we won't have to worry about that in the future.

Giacomino

Wed, 04 Dec 2019 20:13:35 +0100

The advice given by me that, as a user, I have years of experience regarding communication with diaspora protocol:
your diaspora contacts must always add, in addition to the main hubzilla contact , also all its clones.
The good thing is: the posts are never repeated, or they come out of a channel, or come out of its clone, but never dubbed.