Show Navigation
Notices by mike (mike@loadaverage.org), page 4
-
It means that apparently we're on different sides of the international date line.
-
Friendica was my version 1 web communications project in 2010-2012. The basic communications protocol is really old school and I abandoned it and started over because there are so many conceptual flaws in friendica that it wasn't worth trying to fix any more. Many of these flaws still exist.
Hubzilla is my version 3 social communications project. It communicates over zot, Diaspora, OStatus and ActivityPub and provides nomadic identity (your account can be mirrored across multiple servers in case any of them should fail) and also has cross-domain access control of all media and web content you create. It is also a decentralised content management system and distributed permissions system and cloud storage provider. Social networking is just another tool of the hundreds of tools available.
Hubzilla may not be for you - it's pretty versatile. You can use it for a lot more than posting kitty pictures on multiple networks, though you can do this also. The additional functionality is always there if you want it, but can be safely ignored if being in control of your online world scares you.
> #Friendica ist vielseitiger und unterstützt mehrere Protokolle
You really should get out more.
-
Working well in the hubzilla dev branch - I've been using this for lots of stuff... I wasn't trying to copy kanban - it just turned out that the planning tools I created for my own use ended up looking something like kanban.
Plus they have cross-domain privacy and are synced to your nomadic backup accounts and can be shared with the rest of the fediverse.
https://macgirvin.com/cards/mike
-
!federator just a test so I can look at the packets (I'm currently federating forums/groups between ostatus, activitypub, zot, and diaspora).
-
@zoowar I'm sober. You are free to implement ActivityPub and come to your own conclusions about its suitability for the intended purposes. In fact I encourage you to do so. A lot of really bad decisions have been made recently and they say sunlight is the best disinfectant.
-
@verius @veg05 The issue we have is that Mastodon dominates ActivityPub and anything that project decides to do on a whim is being written and hardwired into ActivityPub policy and is driving the specifications. Most of these decisions are short-sighted decisions that only benefit Mastodon, but they affect and limit all future uses of ActivityPub to the lowest common denominator of what works best for Mastodon. So basically they're strangling and killing the protocol before it even has a chance to be a multi-platform communications tool. To be fair, ActivityPub started with a bucket load of problems and none of them have yet been solved in a meaningful way. The specification is weak where it matters and too restrictive where it doesn't matter. If you bring an ActivityPub implementation to the table as we've done, it doesn't matter that you've tried to allow it to federate with the rest of the metaverse and be a communications tool on a level playing field. Your implementation is measured only by how well it federates with Mastodon. The level playing field has already been destroyed. Another few weeks like this and we'll have to abandon ActivityPub for any other use than communicating with Mastodon. That will be its only purpose and it will be unsuited for anything else. I'm well aware of the different federation protocols currently in use. I've implemented Diaspora, OStatus, ActivityPub and invented DFRN (friendica) and zot (red/hubzilla) and for the most part found ways for all of them to co-exist.
-
hubzilla.org
-
We're really,really close to having federated forums that work across Diaspora, OStatus, ActivityPub and Zot; which opens cross-federation with about a dozen projects in the open social metaverse. I just have to finish implementing the ActivityPub bunker buster.
"Mr. Webber, tear down this wall."
-
Looks like Hubzilla accepted the patch and pushed a production hotfix (2.6.2). So this fix should get deployed relatively soon instead of waiting for the next scheduled point release.
-
Most everybody is using rfc7033 (json) webfinger which superceded the XML/XRD based stuff around 4 years ago.
Diaspora moved forward recently and I think Friendica is the only major project still using XRD by default. We have it as a fallback for the one or two sites that don't use SSL, but these are getting rare as hen's teeth. rfc7033 requires ssl and a "valid" cert, but even our test sites can get LetsEncrypt certs these days. In any event you should probably be checking json webfinger first and xrd only as a last resort.
-
The content of the landing page is completely under the control of the site admin from the site settings page. You can direct it to an existing page (such as the public stream or apps collection), to a custom webpage such as a company webpage built using the hubzilla CMS, or an included html file; or even directed offsite to something else. It's pretty flexible.
-
Fixed in commit f1b014b7eb2b44f which should find its way to hubzilla in due course. I retired some months ago so please direct future questions/issues to the hubzilla project and not to me personally.
For curiosity, why are you still using XRD webfinger?
-
I started a long list of issues that weren't even being considered a couple of years ago. I think it was posted to the W3C website. Best I can tell this list vanished. Probably embarrassed somebody that we considered identity and privacy to be social communications issues, but they are. Recently there's been a flurry of activity related to private media and account migration. We've had to fix these things outside the "system" because the system is only concerned with passing messages back and forth.
We're trying to solve privacy and permission and centralisation problems and how do you keep your online identity when the server you're on vanishes without a trace. And we've actually been successful in solving these problems. When I mentioned this recently on the gitforum it was like "right. But *we* didn't invent it, and until *we* invent it, it doesn't exist." And so they start brainstorming about cross-domain auth. Yeah, we tried the iframe thing in 2010. For a number of reasons that was a total failure. We tried several other things before finally settling on cross-domain identity provenance; which actually works. The mobility thing needs to separate who you are from what server you're on. We've even been able to make this work with webfinger. But if your whole idea of identity is user@host, you're going to have serious issues with mobility that can't ever be solved to anybody's satisfaction because as soon as you permanently attach @host to an identity it can't easily refer to you when you post from a different host.
As somebody else pointed out recently, there are a lot of people talking and trying to be in charge, but nobody is listening. They seem to insist that everybody re-invent each wheel. There are hundreds of wheels involved in this process and you're going to spend a long time re-learning the mistakes we already learned from and moved past.
Find out what is going on out here in the real world and in the trenches where we've been working on (and solving) these really hard problems for years now. Every 6-12 months the whole process falls apart and then we start from the beginning again trying to define what a message is and how to get it from point a to point b. That isn't even a real problem. Bloody ship it to port 25.
-
Enjoy every second. In only the blink of an eye she'll be away at university.
-
@utzer - Look around you. The social web is *not* consolidating. The tide is going out. The social web is fragmenting. Friendica as a consolidation project was basically in the wrong place at the wrong time and it's probably going to be a decade or more before the tide turns again.
I love Friendica - I created it. But I moved on. I'm more into building what might be classified as web operating systems these days. They manage permissions, access, and identity.
Friendica was an early attempt at this, but I did a lot of things wrong and really needed to start over to get it right. You don't find out these things until you look at what you've built and see its limitations.
Social networking - is just an app. Yeah, we've got apps in Hubzilla/red. Lots of them. Just like most Linux distros let you run GIMP and OpenOffice. Diaspora is basically a shared library which plugs into the social networking app. And yeah, I know how to implement that - I've implemented variations of the Diaspora protocol 6 times now; including both sides of the new protocol and stuff they don't even support yet like account migration.
So thanks but I do know Friendica and what it can and can't do and I also know how to federate. It just isn't a priority for me in 2017. It was in 2010, but that's long gone. Having roving accounts that are immune to server shutdown and privacy that magically works across domain boundaries are much more important to me these days, and protocol plugins are ridiculously easy to implement - *if* anybody seriously wanted them.
-
I originally created Friendica and then wrote what is now called Hubzilla after pretty much everybody on the web blocked Friendica's attempt at federating the social web. First Twitter, then Google, then Facebook, then Diaspora told us to bugger off and they didn't want us to federate with them. Then StatusNet "became" pump.io but was incompatible with StatusNet federation and we were told to bugger off again.
I thought it was kind of silly to have a project that "federated the entire social web" but was now blocked/prevented from doing so by everybody - including open source projects. Facebook was the killer - we had two-way API federation with them at one time. When that went away the original Friendica dream died; though a few folks stayed on with that project and managed to keep the project alive. But it's nothing compared to what it once was. I used to converse with Facebook and Twitter and Diaspora and GNU-Social friends and mailing lists all on the same webpage; while importing my favourite blogs into my stream via feeds. It was pretty awesome.
Anyway Hubzilla is based on distributed access control and nomadic identity and is probably more of a CMS and personal cloud server than a social network - though folks use it for all of those things. It represents five years of development post Friendica and does a lot of stuff that decentralised networks aren't "supposed" to be able to do. It's strong on privacy and permissions. And we learned a lot from the Friendica experience - all external protocols to other networks are now optional plugins and we don't rely on anybody in other networks for any core services or for our project identity. Once bitten twice shy.
I retired from open source a few months ago. I still help the Hubzilla folks a little bit but I'm doing my own thing now.
-
Your tribe is at war with tribes that think differently and use different algorithms and interfaces to communicate with each other. Whether you like it or not, you're a tribal leader because you're helping to develop those algorithms and interfaces which define your tribe. You might as well have a bulls-eye painted on your forehead.
-
Just tested a proof of concept for federated Wordpress style comments in my personal repo and it works fine. A moderator approval page and a captcha plugin hook and it's good to go. If anybody wanted this I could submit a PR to hubzilla as it's somewhat compatible. Otherwise it will be there for folks to find once I'm gone.
-
Hubzilla has a few solutions relevant to this problem. None are perfect because Hubzilla works best with permissions when your connections are also using hubzilla - as then it can actually determine what permissions apply to remote observers and allow things like wall-to-wall posts/comments. The first would be a permission setting of 'anybody authenticated' for comment permissions. This works today for anybody using hubzilla - and also openid. Friendica auth would probably be easy to add. Diaspora or OStatus probably not - they don't have remote identity support. The second is to create a guest access token (sort of like a dropbox link) and give the access token permission to comment. Several folks have already used these for anonymous commenting. The only problem with the access token is that it's attached to one identity and you can't easily differentiate commenters. But it works today. There's also a two-way post/comment bridge to Wordpress but this doesn't really fit your problem space. Mentioning as it's related.
An ideal solution would be to provide unregistered (ideally moderated) comments just as Wordpress does. The ability would be pretty easy for a clever developer as this has been planned for some time and the data structures support it - just awaiting a motivated developer who wants it bad enough to roll up their sleeves and make it happen. The unregistered bit is almost trivial - just change the comment template to require name and email if the observer is unknown and register the identity on submission. The harder part is managing moderation. Not rocket science, but would take a couple days of work to create a module to list moderated comments and select an action and send out notifications so you know there are comments awaiting disposition.
I retired a few months ago so I have no personal stake in the outcome - I do my own thing these days and not really associated with hubzilla or any other open source project. I think hubzilla offers solutions to a much wider range of problems than most other projects in this space - but that's ultimately for you to decide. Most folks aren't looking for technical solutions but only network effects (whatever is popular at this moment in time). Best of luck solving this particular problem.