I looked at the linked wiki page and stumbled in the first sentence saying:
“[…] installing, customising and developing images for the WD PiCloud”
What-the-heck is WD PiCloud ?!?
(I do have read about the Western Digital Pi Drive, but PiCloud isn’t something I can “get”. Why does the wiki not provide a link to PiCloud resources?)
Because it is (probably “was” unfortunately) a project from WD Labs to create an ownCloud box.
Here is a link: https://owncloud.org/pidrive/
So, you can buy components (PiDrive) today for a Pi and build your own, but that box was better integrated and was coming with the official Snap pre-installed.
I casually named it PiCloud since there was no official name for it.
So, you don’t need one of these devices, you can install this on a spare Pi if it’s connected to a HD or you can create a VM for it. You can get up and running really quickly.
My only Pi at the moment is a Pi 3, which does not seem to be supported (yet).
I’ll see if I can run it in QEmu for testing. (But I’ll probably not have enough spare time before July for this to happen…)
Thanks for your hints.
Cool, there will probably be a better image by then 
Here is a collection of links and resources which may be helpful for implementing this feature:
mod_dnssd to implement Zeroconf support via Avahi. [More docu here]. Debian package name is libapache2-mod-dnssd.Are you aware of Apache module mod_dnssd?
I would start playing with it, if I currently had access to a working ownCloud instance.
It may be the case, that adding this thing alone (with the right configuration) may already be able to publish a generic HTTP and/or WebDAV service announcement which carries ownCloud or Nextcloud in its service name.
Would be great if you can give it a look. Otherwise, I’ll try myself (July or later).
I have a few questions about this feature request:
sudo yum install avahi
sudo systemctl start avahi--daemon
sudo systemctl enable avahi-daemon
Then I can access my NC instances, Jenkins, SSH and everything via that name etc. In browsers, terminals etc. Because I’m running Linux of course.
4. If you need windows users to install SDK’s etc that would make the setup again difficulatier.
5. I think android doesn’t have support for this either.
6. to solve the two above issues you would include the necessary zeroconf code in all clients?
Why don’t create some “official” documentation on the website, how to setup local domains etc?
What would be the advantage of end-users if all this was included? Don’t understand me wrong I like Zeroconf, but I think there is little advantage for the main NC users. Those who would need this feature probably can install it them self, or are helped with a lot of documentation.
What do you think?
UPDATE: note that a NC instance should never have root access to the server. Isn’t this needed to correctly setup zeroconf services?
True.
Unless you also set up the environment for the Nextcloud server to also do “Wide Area Service Announcements”. And if you already have an OurCloud server allowing “out of LAN” clients at all, then you had to configure your domain, router, firewall, DNS, … already, and adding Wide Area Service announcement isn’t that much of extra effort on top of that.
The remote clients would just need to add the domain where they expect TheirCloud servers to be found as a Search Domain in their DNS.
In this case, Zeroconf would also do a lot for remote users. (They would not need to track changed IP addresses or host names – they would track the service name, and every time they would want to access it it would immediately work, even if hostname or IP address had changed.)
Isn’t Apache already a dependency for installing ownCloud? If so, just add the Apache module mod_dnssd as an extra dependency. (On Debian, the package name is libapache2-mod-dnssd).
Here we are…
(Also, most Linux distributions meant for easy usage by end users do already have avahi-daemon running… No need to install it first, then start it manually.)
It seems you didn’t “get” the intention of my feature request at all. Or, more likely: I myself didn’t succeed to present it in a way that leaves no room for misunderstandings – so “mea culpa”.
No, of course I do not want Windows users to install SDKs. I want the developers of Windows client applications to install the Bonjour SDK in order to include the Zeroconf functionality into the client itself. So the user, running the client, will just “see” which OurCloud services are available.
What I want is that OurClouds make conscious use and take real advantage of what improvements the Zeroconf technology (a.k.a. “Bonjour” on OS X, a.k.a. “Avahi” on Linux) already provide. That potential is not yet tapped!
I think, your thinking isn’t correct – but I may err. Even if you are right: would that be a reason to not support easier setup for users of other platforms?!?!?!? Whats the point of your “point 5”? I don’t understand this statement.
Which “two above issues”?
But yes, all clients which want to support Zeroconf, would have to include code to add that functionality…
OurCloud setups would be easier to achieve. OurCloud service discoveries would be easier and faster, (initial) connections would require less typing and clicking. End-users wouldn’t have to bother if the OurCloud server changed hostname and/or IP address. End-users wouldn’t need to figure out where-the-heck the relevant documentation is, read it all, understand it all, apply it all…
I believe that you like it, but I do not understand why you like it then. Zeroconf is a huge improvement for all users, especially users of mobile devices. It would equally improve ease of discovery and use for OurCloud services.
Why do you think “AirPrint” for iOS was so much of a success that printer vendors stumbled over themselves and their competitors in order to make all their new devices to support it? Because it makes printing from iOS so much easier and faster. And because – I’ll tell you a big secret now! – AirPrint is based on Zeroconf. Zeroconf is what Apple implemented under the marketing name of “Bonjour”.
Completely wrong! (IMHO )
Those who need it most, are probably least capable to install it themselves.
Those who are capable to install it themself do need it least.
And “helped with a lot of documentation”?? This is what does never help average end users. This only ever helps geeks, nerds, power users, administrators and developers…
No, it’s not. (DNS-SD/mDNS use port 5353, access to which does not require root.)
Since you have avahi packages installed, just try to run this command from a terminal as a non-root user:
avahi-publish \
--subtype=_universal._sub._ipp._tcp \
--service "Minimal AirPrint Fake via Raspbi (fooling iPad clients)" \
_ipp._tcp \
666 \
pdl="image/urf" \
URF=""
(the command will not return – don’t press ^C, otherwise the announcement will be shut down again).
Congratulations!, you have just created a Zeroconf service announcement fooling iPads on your WLAN to think there’s an AirPrint-capable device around. Did you need to be root?
You can check for the “success” of that announcement…
…either by taking an iPad or iPhone, open the print dialog in any application and browse for printers,
…or by starting avahi-discover (a small GUI for browsing DNS-SD/Bonjour service announcements),
…or by running (in a different terminal!) this command:
$ avahi-browse -t -a
and as a result you should see something like:
+ wlan1 IPv6 Minimal AirPrint Fake via Raspbi (fooling iPad clients) Internet Printer local
[....]
You can also create a usable/useful service announcement, publishing how to access the existing ownCloud demo server:
avahi-publish \
--service "The Real ownCloud Demo Server" _http._tcp 80 \
--host demo.owncloud.org \
path="/apps/gallery"
Voila!, you have just created a service announcement on your LAN and/or WLAN that lets all users with browsers supporting Zeroconf find the ownCloud demo server:
Excuse me for my misunderstanding, I do understand you feature request now 
I was thinking you just wanted a system so inside ownCloud you can make it to work via .local addresses.
Now I really see the potential of you feature, and indeed if you adapt the android/windows clients etc you don’t need platform support.
I’m glad I was able to convince you 
I hope you’ll vote for it too (however I don’t know yet if there is such a mechanism here).
All my examples above are only meant for potential developers of this feature. They may not be familiar with Zeroconf/Bonjour/Avahi – so all my examples were there in order to help them getting a grip on the topic, and to help them start playing with the interfaces and tools which are available.
I added a fifth user story (“Olivier”) in my original post above in the hope to make the use cases for this feature more clear to readers.
While is see cool potential here I’m not sure about the usability just yet. Currently you need to provision accounts etc anyways.
I mean it is all nice and well that a friend of mine knows that I have an instance running at x.y.z.42 but then what?
The thread is so long so I can’t even read it, but anyway, what about to implement this?
I have a Turris Omnia router with OpenWRT and NC installed and I need mDNS discovery for three use cases:
On the router I manually created /etc/umdns/nextcloud.json file where advertised WebDAV shared folder so the problem 2 and 3 now solved.
But iOS app still needs for a manual configuration.
Also I see a usage scenario to synchronize calendar with CalDAV.
Just found an issue on GitHub on this Use Zeroconf technology (a.k.a. “Bonjour”, a.k.a. “Avahi”) for DNS-SD (DNS-based Service Discovery) · Issue #39 · nextcloud/server (github.com)