Mon, 25 Mar 2019 11:23:23 -0300

Mario Vavti via Zotlabs|Hubzilla Development

mario@hub.somaton.com

I have been looking at how the sync of comments of non-nomadic posts (diaspora, AP) works and eventually came to the conclusion that it would be best to remove this functionality.

Here are my reasons:

It will not work anymore as soon as the hub where the non-nomadic contacts are connected goes down
It is hard (maybe even impossible) to make it work in a consistent way (especially for AP)
It's an ugly workaround to make non-nomadic platforms look like they are nomadic

Any opinions?

!!zotlabs.org | Hubzilla Development

show all 51 comentários

Mon, 25 Mar 2019 12:49:47 -0300

M. Dent

dm42@hub.webgoeslocal.net

From a technical vantage point, I agree.

I think I would actually like to see a 'is_nomadic' designation added to the add-on description block (maybe in the apd file). Then add a pconfig variable that can be checked to see if any non-nomadic addons are installed.

If 'is_nomadic' is not set to true/yes, then the addon is not installable if the channel exists on more than one hub. Also, when a single homed channel installs a non-nomadic add-on, it sets pconfig.nonnomadicaddons. Then, during channel cloning, 'pconfig.nonnomadicaddons' is checked and if it is set, channel cloning fails.

On the other side of things, I think a special channel type of "reflector" or "bridge" could possibly be created that is linked to a nomadic channel on one side and acts as the person's identity on the non-nomadic networks on the other. Of itself, it would not at all be "portable" but would allow the functionality that people are desiring.

It's very low on my personal priority list because I'm not much interested in the non-nomadic networks right now. But if someone else headed up coding, I'd be willing to discuss the general roadmap and concept and help figure out the mechanics.

Parts of pluggable "core" for such a beast MAY be on my roadmap in the next 6-12 months for other purposes. If so, it will still likely require someone else to apply a bit of effort to make it work for the existing protocols.

Mon, 25 Mar 2019 16:10:46 -0300

Waitman Gobble

waitman@hub.zilla.tech

I don't have any connections with people on those networks, so it's ok with me. But I think Manuel uses it?

Mon, 25 Mar 2019 17:13:54 -0300

Robert Kormann

robert@rkor.info

Mario,

I am not sure if I got the point right - comments on Diaspora and Activity Pub related channels are about to disappear, right? - and I am not sure, if I deserve to have an opinion seeing my small role within the fediverse. But that is my main point: the fediverse, not the zotiverse.

Since I am only active for a few months, I remember my own decision making. There were several points bringing me to Hubzilla:
- Software running on a LEMP stack (own hub)
- Being in my case more interested in macro- then in microblogging
- Being part of the whole fediverse using plugins
- Nomadic identity is a good thing

At the moment, 64% of my contacts are coming in via Zot, 28% via AP, and the rest via Diaspora, with some of the most active channels coming via AP.

If technical difficulties lead to some oddities in these comments, so what, if 95% is fine. Sorry for saying that, but being cut away from - mostly - AP comments would be a thing hard to accept for me.

Robert

Mon, 25 Mar 2019 17:17:10 -0300

Mario Vavti

mario@hub.somaton.com

@Robert Kormann you misinterpreted me. I am only talking about syncing posts from Diaspora or AP to channel clones. Not about the ability to connect to AP or Diaspora with your channel.

Mon, 25 Mar 2019 17:28:14 -0300

Robert Kormann

robert@rkor.info

@Mario Vavti Ah, ok, "sync of comments" is between the clone and the channel. Then forget about my comment.

Tue, 26 Mar 2019 05:27:38 -0300

El Dorado

mike@z.macgirvin.com

@M. Dent The reflector/bridge is what I set out to accomplish with Osada and therein lies a working prototype. I've been working on various solutions to this paradox literally since the first demonstrations of nomadic identity. There is no solution, it is a paradox.

My $0.02. ... We've got a smoke and mirrors solution which provides an illusion that nomadic identity and federation work together. They don't. Turn it off. Let's stop pandering to people and force them to own their bad decisions. I would go so far as to prohibit installing the Diaspora and ActivityPub apps until you remove all your clones and change your privacy role to the "I want more spam" setting. But I'm not that cruel and that's why I'm doing Zap now. It does not have these conflicting choices.

Tue, 26 Mar 2019 05:31:11 -0300 última edição: Tue, 26 Mar 2019 05:32:53 -0300

Max Kostikov

kostikov@tiksi.net

The ability to interact with other popular Fediverse networks (more popular than Zot now) is one of those features why people choose Hubzilla. I understand there is a lot of difficulties on that way but hope that those problems can be resolved if not totally due protocols incompatibility but in the basic. At least @Mario Vavti last patch works well and issue with Diaspora duplicated comments looks solved.
@Manuel

Tue, 26 Mar 2019 06:04:14 -0300

Mario Vavti

mario@hub.somaton.com

@Max Kostikov nobody is talking about removing federation with other protocols. It's about syncing federated connections to channel clones and back.

Tue, 26 Mar 2019 06:09:02 -0300

Max Kostikov

kostikov@tiksi.net

@Mario Vavti Sure, I understand it. But many users are confused on clones and other networks connection incompatibility.

Tue, 26 Mar 2019 06:11:46 -0300

Mario Vavti

mario@hub.somaton.com

But many users are confused on clones and other networks connection incompatibility.

What is your proposed solution to this confusion?

Tue, 26 Mar 2019 06:23:09 -0300

Max Kostikov

kostikov@tiksi.net

I see two ways. 1st try to get it work. 2nd to better inform users about clones and non-nomadic networks incompatibility.

Tue, 26 Mar 2019 09:21:43 -0300

M. Dent

dm42@hub.webgoeslocal.net

IF it is possible to get nomadic/non-nomadic protocols to work such that a channel can be nomadic and have reliable and stable connectivity to non-nomadic networks (I'm not absolutely convinced either way) the time investment is more than any current dev is willing to make as far as I can tell.

I have some ideas, but no time (or real incentive) to try to implement them. Based on my current (incomplete) understanding of the code, and protocols, the investment required to do it is significant... And so it becomes a question of whether or not it is "worth it". How many of these protocols will be around and in substantial use in 3 years? And, there's the question of whether such an effort would not merely cause some of the protocols too long outlive their useful lifespan. I like digital nostolgia as much as the next guy, but it doesn't pay the bills or get productive work done.

As for user education and settings expectations - if it isn't stable and reliable, it needs to be very difficult to make happen. That's my view. That's really the only way to clealy say that, "this is an unsupported configuration - if you do this, you're on your own". Config variables are by nature "supported" even of undocumented. It needs to be a hard coded rule that separates nomadic/non-nomadic configurations.

If someone goes in and changes the .apd file to make an add-on nomadically compatible when it is not - well - there it is.

Of course the invitation is always open, 'if you get this to work reliably, we'd love to merge it a pull request!". But until there is someone with an obsession for self harm who wants to bloody their forehead against that wall, I don't see a long term supportable and maintainable path. @Mike Macgirvin tried and it was a huge sacrifice of time and energy. Just because he wasn't able doesn't make it impossible, but it is clear that the effort required and the incentive and dedication would need to be significant. I personally have no incentive and have enough trouble dedicating myself to things I really want to see happen for the platform. Mario is carrying a heavy burden keeping things humming as it is and he is the one making the proposal to remove back away from trying to support it which if we take his post at face value gives a good indication of his mindset.

I think it would be great to be able to make it all work... But there is an opportunity cost to doing so (if it is even truly possible - and the resident expert has numerous times indicated it is not truly possible). I see only one logical path. Remove support.

The user education side would be, "set up a non-nomadic channel for your non-nomadic activity." To live in two world's requires two houses. It is impossible to have only one dwelling and live in Los Angeles and NY City at the same time.

Now, there are some configuration settings that can make switching easier. There are also some (as yet) unpublished addons and others that could be written which may be helpful and help manage the two "homes". But fully separating nomadic from non-nomadic is really the only legitimate option I can see.

Choosing the constant "wait till it breaks again and then patch it" will continually leave open the charge that "Hubzilla is buggy and unreliable". We need to put that to rest. Hubzilla is VERY reliable and stable - when used in a supported configuration. We need to make it more difficult to set it up in an unsupported configuration - or we will spin our wheels constantly supporting what we say we don't support.

Tue, 26 Mar 2019 11:13:07 -0300

Giacomino

giavec@zotum.net

6 d. ago I posted ...

https://zotum.net/channel/giavec/&mid=b64.aHR0cHM6Ly96b3R1bS5uZXQvaXRlbS9iZjg5MzI5Zi1kOGRmLTRkODUtYjE5My04MjlhNDQzNTliN2Y

... and I did 'cause I'm tired (just as a helper and not as a dev) of repeating the same things all the time, and spending more energy on known things.

Tue, 26 Mar 2019 16:41:20 -0300

El Dorado

mike@z.macgirvin.com

Here's the problem. You have a channel on hub.site.a and a clone on hub.site.b. From hub.site.a you connect with somebody on diaspora.site.c.

hub.site.a is suddenly shut down. That's fine. You go to hub.site.b.

Now you post a message from hub.site.b. Your friend at diaspora.site.c does not receive it, because they don't know who you are. You are not a friend. Your channel on hub.site.a is.

Your friend at diaspora,site.c posts a message. You do not get it, because once again - you are not a friend of theirs.

Now here's what we currently do and what Mario is proposing we drop:

You decide to use hub.site.b, even though hub.site.a is still running and hasn't been shut down. You post a message.

The message you post at hub.site.b is sent to hub.site.a - which sees that you have "singleton" (non-nomadic) connections. It delivers them. The diaspora person gets a message from you at hub.site.a and everything is fine, you're a friend of theirs.

The diaspora member sends a message. It arrives at hub.site.a and is accepted (because you are friends). It sends a clone of the message to hub.site.b where you see it.

All is fine as long as hub.site.a is running. This is the smoke and mirrors part. If hub.site.a becomes unavailable for any reason, everything breaks. You may have been happily using hub.site.b for a year and it worked so well that you forgot you had clones on hub.site.a. We actually had this happen a few years back with Sean Tilley who knew and understood and even acknowledged that cloning and federation weren't compatible, but did it anyway. Much later he moved permanently to his clone (everything still worked at this point for several months) and only later shut down his original site and when he did, all (several hundred) Diaspora connections immediately stopped working.

So if we remove the smoke and mirrors, your clone will only ever work with your nomadic connections. You will have immediate feedback that your singleton friends are gone and you won't get lulled into a sense of false security that everything is fine.

Tue, 26 Mar 2019 16:52:19 -0300

Max Kostikov

kostikov@tiksi.net

Thanks @Mike Macgirvin ⚡ for detailed explanation. That's what I suspected.

Tue, 26 Mar 2019 18:15:15 -0300

hEARt PhoniX

tobias@hubzilla.rocks

Tue, 26 Mar 2019 18:36:01 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

I agree with the proposal. When connecting with AP and Diaspora we should live the fact that those connections will be operating on a non-nomadic basis because, well, those protocols are non-nomadic. We should be careful when allowing those protocols to be active in more than one clone, however, as members might start making connections from different clones and not understand why messages are not getting to and coming from all their contacts. One solution would be for the addon to, once enabled, disallow enabling in other clones unless a big "advanced usage, do not expect it to work as you imagine" box is marked.

Tue, 26 Mar 2019 19:02:34 -0300

M. Dent

dm42@hub.webgoeslocal.net

As mentioned, I wouldn't even make it a check box or option anywhere. I would build in hard coded checks so that channels with clones cannot enable non-nomadic plugins (period). And a channel with non-nomadic plugins can't be cloned (period). The only way around it would be to actually mess with the PHP code of the installation. I think that is the only way to be exceedingly clear that "we don't support this usage - yes, it may be possible, it may even seem to work, but we don't support it and highly caution against it... if you are mess with the code, and something breaks, you did it to yourself.". (I would also put almost exactly that "warning" in the code where the checks are performed)

Tue, 26 Mar 2019 19:04:49 -0300

M. Dent

dm42@hub.webgoeslocal.net

Also - as mentioned - I think there ARE ways to teach people how to get the basic functionality they want without resorting to editing the code. Some video tutorials about it would be an awesome addition to the doco.

Tue, 26 Mar 2019 19:25:37 -0300

Alexandre Hannud Abdo

aleabdo@hubzilla.com.br

@M. Dent I think you're overreacting. The mess is syncing between clones, not their existence. We federate fine with other networks as long as that communication stays non-nomadic, forever trapped to a member's "singleton hub", which is what their protocols demand.

Moreover, a member powered with clones but constrained to use mainly their singleton hub because of contacts in non-nomadic networks will be much more aware of the fragility of those links, which may well entice them to campaign with their contacts to move to Hubzilla so they can all profit from freedom and actual decentralization.

Tue, 26 Mar 2019 21:16:41 -0300

M. Dent

dm42@hub.webgoeslocal.net

@Alexandre Hannud Abdo -

If we are talking about the sophistication of Hubzilla's current user base, I agree. If we are talking about the potential (dare I say target) user base which in many cases lacks this sophistication, I think a bit of "overreaction" is warranted.

The user who has the awareness that you describe should feel comfortable and confident enough to make the needed tweaks to the code to make it work.. And they are going to be self aware enough not to publicly whine that Hubzilla is "broken" when a configuration that is described as "unsupported" doesn't work.

On the other hand, those that lack the sophistication you describe are more than happy to loudly and proudly declare that Hubzilla is a busted crappy piece of software and that the devs don't care about users because resources and time is not spent fixing problems with an unsupported configuration.

Even when the discussion is more polite and nuanced than my crass statement above (which in this case it generally has been!!) a new user or potential new user who sees a report every couple of weeks or few days asking for help because this unsupported configuration is misbehaving will jump to the conclusion that Hubzilla is buggy and the devs aren't interested in fixing it simply by the sheer volume of requests. (Heck, even now I feel guilty and ashamed just reading the reports and feel like I need to drop everything and work on it -- that is to say the sheer existence of the reports is demoralizing to developers - and we don't need that!)

So, again, if we are only interested in supporting the current userbase, I agree, my suggestion IS an overreaction, but my scope is wider than that and includes the less savvy who we yet hope will get on the clue-bus and join us.

Tue, 26 Mar 2019 21:20:19 -0300

M. Dent

dm42@hub.webgoeslocal.net

All I am suggesting is code changes that enforce the fact that non-nomadic addons can only be installed on non-nomadic channels. That's it. But ultimately I do think it needs to be an enforced code-based prohibition - not something that is simply a " check box override".

Wed, 27 Mar 2019 02:27:59 -0300

El Dorado

mike@z.macgirvin.com

If you want to go the enforcement route, the most sensible way to do it is to have all their Diaspora and Mastodon friends vanish on their clone site. Not some warning that they may not be reachable, but poof - they're gone. Then people will start to get the message.

Wed, 27 Mar 2019 03:48:39 -0300

hEARt PhoniX

tobias@hubzilla.rocks

Wed, 27 Mar 2019 05:02:57 -0300 última edição: Wed, 27 Mar 2019 05:27:45 -0300

Max Kostikov

kostikov@tiksi.net

And what about idea to use hub-related channel name to establish contact with non-Zot networks?

Let's use @Mike Macgirvin ⚡ example.

You have a channel on hub.site.a and a clone on hub.site.b. From hub.site.a you connect with somebody on diaspora.site.c.

When you connect to diaspora.site.c from primary channel localtion you use your_channel_name@hub.site.a and when you reestablish connection from clone you use your_channel_name@hub.site.b. At Diaspora side two contacts will apeared (but who cares) and as result all updates will be sent to both Hubzilla hubs. Now even primary location hub will be down we'll get all in hub were clone is.
At our side we will need to sync those updates between both locations and ignore duplicates.

Wed, 27 Mar 2019 05:32:38 -0300 última edição: Wed, 27 Mar 2019 05:33:14 -0300

Mario Vavti

mario@hub.somaton.com

@Max Kostikov basically then the singleton contacts will receive each message twice or even more often if there are more then one clone.

Wed, 27 Mar 2019 05:35:32 -0300

Mario Vavti

mario@hub.somaton.com

Possibly leave it up to the channel owner if and when to reconnect to singletons from the new location?

Wed, 27 Mar 2019 05:44:01 -0300

Mario Vavti

mario@hub.somaton.com

@h.EAR.t federation social is a set of permissions. No more no less... Connecting permissions with the ability of cloning or installing certain apps is not the way to go imho.

Wed, 27 Mar 2019 05:47:24 -0300

Max Kostikov

kostikov@tiksi.net

@Mario Vavti Sorry, I didn't get your thought.

Wed, 27 Mar 2019 05:53:40 -0300

Mario Vavti

mario@hub.somaton.com

@Max Kostikov if hub.site.a and hub.site.b are both connected to diaspora.site.c then diaspora.site.c will receive each post twice. They will not like that...

Wed, 27 Mar 2019 06:01:36 -0300 última edição: Wed, 27 Mar 2019 06:38:57 -0300

Max Kostikov

kostikov@tiksi.net

@Mario Vavti We can send post to Diaspora only from hub where it was created then sync on clone and ignore further dupicates.

Wed, 27 Mar 2019 07:33:07 -0300

hEARt PhoniX

tobias@hubzilla.rocks

Wed, 27 Mar 2019 07:44:46 -0300

Mario Vavti

mario@hub.somaton.com

@h.EAR.t IIRC the "social federation" permission role allows everybody authenticated to comment on your posts by default (which is the standard in diaspora and mastodon). It does not solve any federation problems otherwise...

Wed, 27 Mar 2019 07:49:20 -0300

Mario Vavti

mario@hub.somaton.com

I use the federation apps with this channel, but i do not have this channel cloned anywhere so federation works well. I don't want to allow anybody to comment on my posts though just because i use the federation apps...

Wed, 27 Mar 2019 09:11:07 -0300

hEARt PhoniX

tobias@hubzilla.rocks

Wed, 27 Mar 2019 09:37:59 -0300

M. Dent

dm42@hub.webgoeslocal.net

The "permission role" setting isn't actually a "setting" it is a meta-setting or a settings template. Aside from recording which option was chosen, I don't believe the value itself is used in ANY decision making. Rather, when you choose one of the roles, it sets a bunch of other options to cause Hubzilla to behave in the manner described. After the initial setup, those options can be changed/overridden directly. The "role" is not referenced at all for anything else as I recall.

The only thing I'm unsure about is, if you change the role after initial channel setup, does it UNSET things and configure the new role or does it do some funky "merge" and simply add the settings that were not in the original role?

Wed, 27 Mar 2019 14:57:55 -0300

Max Kostikov

kostikov@tiksi.net

Hmm, I just found that Hubzilla already acts as I proposed above. My cloned channel presented in Diaspora twice so both location receive updates from there.
So if we can be able to send post to Diaspora directly from origin location and then sync own content between clones, detect and depress duplicates it should solve incompatibility with clonned channels.

Wed, 27 Mar 2019 15:01:40 -0300

Mario Vavti

mario@hub.somaton.com

@Max Kostikov Did you connect from the clone location manualy?

Wed, 27 Mar 2019 15:05:18 -0300 última edição: Wed, 27 Mar 2019 15:07:26 -0300

Max Kostikov

kostikov@tiksi.net

@Mario Vavti Yes. And as I recalling I did it from Hubzilla side not from Diaspora.

Wed, 27 Mar 2019 21:46:15 -0300

M. Dent

dm42@hub.webgoeslocal.net

But this would be unintuitive for Mastodon/Diaspora users. If I want to send you a private message from Mastodon/Diaspora, which address would I use? Would a Mastodon/Diaspora user know to send it to ALL of them? Wouldn't they be confused by multiple accounts for a single friend - maybe suspect forgery or something bad is happening? And how do we convince the Mastodon/Diaspora users that they are not only all legitimate addresses for the intended recipient, but in any direct messages, they should use them all?

Thu, 28 Mar 2019 05:20:43 -0300 última edição: Thu, 28 Mar 2019 10:35:13 -0300

Xanthor

xanthor@ussr.win

Just tell them there are aliases (it's already what we do with email addresses, right?)

Thu, 28 Mar 2019 05:34:47 -0300

Max Kostikov

kostikov@tiksi.net

@M. Dent I'm worrying mostly about Hubzilla user experience. Personal messaging can confuse Diaspora users but posts and comments are more often activity in Fediverse. I believe this can be easily explained to them in the first message.
@Xanthor Yes, it's similar.

Thu, 28 Mar 2019 09:23:10 -0300

M. Dent

dm42@hub.webgoeslocal.net

I believe this can be easily explained to them in the first message

I think you over estimate the desire of third party users (eg. of D* and AP networks) to be taught and learn about the idiosyncracies of other platforms. If I were a user on one of the other networks, irrespective of the technical superiority of Hubzilla, I would consider this behavior as definitive proof that it is busted software.

I believe this solution will be harmful to the overall "brand image" of Hubzilla.

Thu, 28 Mar 2019 09:33:38 -0300 última edição: Thu, 28 Mar 2019 09:40:29 -0300

Max Kostikov

kostikov@tiksi.net

@M. Dent Perhaps. But if we trying to respect other networks features and patterns of other networks why we shouldn't expect that their users will so kind to respect ours? This is two ways road.

Thu, 28 Mar 2019 09:49:53 -0300

M. Dent

dm42@hub.webgoeslocal.net

Because that's called "imposing on others" and others don't like to be imposed upon. You can't demand other people be nice to you. It doesn't work. You can only control you.

In the case of Hubzilla, the history that I have seen is that we have been the nice guys always willing and making every effort to accommodate and make up for the deficiencies of other systems. From what I have seen, every request for accommodation made by Hubzilla to the other networks has been rebuffed - strongly. From what I can tell, this is a primary reason Mike has washed his hands with the Federation protocols.

I'm sure there is 'more to it' and there are always three versions to every story (person A's version, person B's version, and the truth) but I have seen some of the threads and witnessed some of the attitude held by major players in some of the other platforms... And if they are ANY indication, what you propose will only be used to confirm the notion, "Hubzilla is a broken piece of shit software" and reinforce the "avoid at all costs" mantra.

Fairly or unfairly, rightly or wrongly, that is what seems most likely and I don't think we should go down that road.

Thu, 28 Mar 2019 10:00:18 -0300 última edição: Thu, 28 Mar 2019 10:07:55 -0300

Max Kostikov

kostikov@tiksi.net

Ok, I got your point and mostly share it.
All I can say is I don't understand why we should to limit features for Hubzilla users in favor of other networks. At this moment in dev after last Mario fix I see no issues with Diaspora in clonned channel.

Thu, 28 Mar 2019 11:54:50 -0300

M. Dent

dm42@hub.webgoeslocal.net

As Mike said, it's "smoke and mirrors." I'm not really "in favor" of limiting those features, even though it may seem like that. I just see that as the best overall path for the project given all the factors involved.

Overall, I am in favor of modularizing those features and organizing them in a way that reduces confusion for users and makes it clear at an interface level what the consequences of their decisions are and to make it easier for users to more intuitively see where the problem is when things come up.

Right now, it is "magic". I don't like "magic" software. I like it when it FEELS magical - but not when it IS magical.

Right now there is some "hocus pocus" magic things we do to make everything seem to work - but we also know for certain that there are critical failure points that will cause it to stop working without any way for the user to know or understand WHY. To regular users, that looks like "broken" software.

My proposal is simply to manage expectations. In the best of all worlds, I would not want to change what CAN be done using Hubzilla - but only to change HOW it is done. In this case, i see it as a multi-step process that will take time and effort.

I think it's best to try to do this NOW, while the current user base is small - and it is easier to communicate "we need to break things in a very specific way in order to fix them for long term maintainability, in order to maintain current functionality you will need to do X, Y, and Z - and the developers are going to spend their effort on the long term maintainable solution and very little effort on 'break-fix' patches - so if you choose to continue doing this, expect rough patches."

Of course, this is all predicated on the ability to have development resources to commit to the long term solution. But if we don't have resources to commit there, we don't really have the resources to be doing 'break-fix' on the current solution either, because it will be an endless cycle and the effects of that cycle will harm the project's reputation and long term potential.

IF you accept all of that as true (we don't have the dev time to do a long term maintainable fix - and a constant break-fix cycle is harmful to the project), then the logical action to take is to simply remove the functionality entirely and block the ability to use it and declare it "unsupported" and then cease supporting it and take the hit on the user base that is trying to do something outside the main core and focus of what Hubzilla IS rather than stretch our limited resources too thin and end up doing nothing well.

This isn't the BEST solution in my view, but it is the PRACTICAL solution and the best POSSIBLE solution given the limitations of resources.

If Mario's fix works, then maybe we are "nearly there" and the effort needed to create a modularized solution is less than perhaps it first seemed - and so it may be something that is in reach given the development constraints that we have.

But I maintain that it is an objectively BAD IDEA to keep it in the current "magical" state any longer than absolutely necessary. I think that a channel clone acting as a bridge to non-nomadic networks needs to be a clearly defined different "thing" than a regular nomadic channel clone.

Thu, 28 Mar 2019 12:01:10 -0300

OJ Random

ojrandom@hz.raspberryip.com

I would follow the KISS principle. If federation is on then no clones.

This could save much pain on every side.

Neither the average user is aware of clones nor the average developer. I guess most of them would deny that something like clones exists at all AND is working.

Thu, 28 Mar 2019 13:27:32 -0300

M. Dent

dm42@hub.webgoeslocal.net

Here's how I personally see such a "bridge" working best:

1) The Singleton is a specialized channel type that acts as a special case "clone" (some limitations on what does/doesn't get "synchronized" may need to be added - see below).
2) Non-nomadic network addons can only be installed on a "singleton" channel
3) Nomadic channels can only access addresses of non-zot networks if they have a specialized "singleton connector" addon installed which links their channel to the singleton "clone". (A separate "singleton" addon is installed on the singleton itself)
4) ONLY the channel address of the singleton channel is ever seen by non-nomadic networks.
5) The "singleton connector" addon permits linking to no more than ONE singleton "bridge".

ADD CONNECTION/ADDRESS BOOK

If the "singleton connector" addon is installed, first attempt to look up the address via ZOT, then pass an API call to the singleton (via the "singleton connector") to see if it can make the connection via a non-nomadic network.

Unless the "singleton connector" addon is installed, a clone does not have the ability to specify non-zot addresses on outgoing messages or even "see" them in their address book - though - because of the message routing (see below), they should still see non-zot identities in conversations.

MESSAGES

For outgoing (top level) messages from zot channel clones the singleton node is responsible to redistribute to non-nomadic addresses. (this is basically what I understand occurs now)

Incoming (top level) messages get forwarded ONLY to channel clones running the "singleton connector" (While not ABSOLUTELY necessary from a technical vantage point, the reason for this is to keep the user mindful that there is something special about connecting to non-zot network addresses. Also, the "singleton connector" can provide feedback and information about the health of the singleton relay node).

Incoming REPLIES to ZOT toplevel messages coming from non-zot networks are received by the singleton and follow the current rules for replies with the addition that a copy needs to be forwarded to each channel clone. (For thread continuity, I would NOT require that the "singleton connector" be installed on the clone if the message is a REPLY - otherwise the thread will have different views based on which clone is being used).

Outgoing REPLIES get treated as they do now (a copy going to each channel clone) with the singleton node responsible for redistributing to non-nomadic addresses.

======

If I am understanding things properly and if the latest round of "fixes" actually deals with the issues we've seen, MOST of this is actually what happens now. The only additional "layer" is the "singleton"/"singleton connector" addons which would serve as a trigger for enabling this functionality, provide a mechanism for user feedback regarding the health of the singleton node itself, and add the ability to add non-zot addresses from any channel clone running the "singleton connector" - not just the clone running the non-nomadic addons.

If I had the time and inclination - that is how I would approach things.

Thu, 28 Mar 2019 16:54:00 -0300

El Dorado

mike@z.macgirvin.com

Seriously we've been down all these roads before. They are all dead ends. Nomadic identity and "the fediverse" are not compatible. You can waste years trying to make them get along (as I have) or you can acknowledge this simple fact and get on with your life (as I have). As Mario suggested in the top level post, people will never understand that these things are incompatible if they can test it and "hey it works" (it doesn't really, but they feel good about it and tell others that we're lying about the incompatibility). Let's stop pretending. Two lines of code and their tests will result in what we've already told them - it doesn't bloody work. End of story. Get on with your life.

Thu, 28 Mar 2019 20:49:54 -0300

Giacomino

giavec@zotum.net

and I also suspect that for activitypub , things get even more complicated, worse than the attempts made for diaspora protocol/networks