Notices by mike@loadaverage.org
-
iCal is the one thing that nearly every software vendor agrees on when it comes to federating events and attendance. Everybody still tries to roll their own - I know; I've done it myself.
Eventually they all come around and realise that if you want to federate events across multiple platforms there's only one game in town.
-
I recently saw a unique/novel solution - provide the full edit history but allow you to remove revisions edits if they contained sensitive info. I'm not sure anything is gained this way since those using edits for juvenile games would similarly delete the original; but it does address my concerns about being forced to provide an audit trail. There are legit reasons why you might want the history truncated.
In any event I haven't encountered any such antics/pranks since I started providing edits in 2010. If it did happen, I'd unfriend or block the person and move on. I'm not big on following the public streams because these subject you to a wide range of bad behaviour. If you live in the public stream, juvenile edits might indeed be a problem but a minor problem in comparison to other bad behaviour you'll encounter.
-
@tagomago Actually a fail of both ActivityPub and Diaspora. These protocols don't permit relaying of comments from other protocols.
@trixty Hubzilla does allow feed aggregation, but your site disabled this recently. IIRC somebody was trying to snarf a feed that was tens of gigabytes in size and this was causing problems.
-
@lnxw48a1 What did you find in the config that is concerning? I'd be glad to have a look.
-
Two cryptos with onions please.
-
Bloody hell. They always give me Whitney Houston or the star spangled banner. Hint: anybody can sing the us national anthem. It doesn't take training or skill. It takes attitude. If you miss some notes they'll crucify you. If you sing it with attitude, they'll give you a standing ovation for the missed notes. Oh and booze. It takes booze.
-
> In short: it's much better to have separate, dedicated apps that focus on one thing and do it well, and have them communicate over a common language.
Ironically, that's basically the model of how Hubzilla works. It is a web platform that provides a common privacy implementation and a rich set of services to applications such as theming and layout. The various modules (wikis, cards, events, whatever) are for the most part optional and each does one thing. Some are serious counterparts to standalone web servers, some are just simple interfaces to do something very specific. How they fare at doing their job "well" is mostly a matter of whether or not developers are invested in that particular module. It isn't unlike Unix itself. There are a bunch of social networking modules serving different protocols and communications with WordPress and RSS/Atom feeds (for instance). There are several different content publishing tools and file managements services. There are other apps - games and mapping services. What they all share is the common privacy framework and layout engine.
It's a different way of providing web services than providing an array of standalone webservers using different languages and completely different user interfaces and trying to manage logins and permissions across all of them. One for file management, one for communications, one for wikis, feed readers, etc. People have tried this. Heck I've tried this. You can't really. Anyway, if it's not for you, nothing I can do about that. But there are solid reasons why it has to be this way and why somebody has to provide this kind of tool.
-
If all you want is the social bits, and don't give a rat's bum about privacy and who can see your photos/videos/whatever, stick with Mastodon. If however you want the decentralised privacy bits and want to control who can access your web assets without requiring them to have a login account on your server, there is only one game in town.
-
and mastodon looks like a geocities gamer site from1995 except for all the japanese kiddie porn. If your software is any good you can change the UI just like you change a shirt. A billion people used facebook in 2009, despite hundreds of pages of privacy settings and thousands of features and 'vendor integrations'. #justsayin
-
Thanks for that. There was no such link when I did look into this a few months back.
The reason we integrate all this stuff is because it's the only way you can have a consistent approach to decentralised privacy. Otherwise you have different ways of sharing your photos and videos (etc.) privately and none of them work together and it all breaks if you move servers.
We actually do listen to people, just different people than you listen to. That's not a bad thing - there's room for everybody.
-
Or you could use hubzilla and have photos and videos with DAV access and events and webpages and wikis and decentralised permissions/privacy attached to all the above and have nomadic identity and communicate with folks on activitypub and diaspora and ostatus to boot.
And if @chocobuzz would just provide a magnet link we wouldn't need to execute foreign javascript across domains (presenting a huge security risk) but could just fetch peertube videos and photos direct from webtorrents and embed them as native objects.
#justsayin
-
Yup. I pointed out a bunch of critical show-stopper flaws and explained repeatedly why they are show stoppers. They are all still there - every one of them. But if Mastodon wanted a flag to indicate whether or not you brushed your teeth this morning, they'd have it implemented the next day.
-
Missed this first time through. Hubzilla has delivery reports. We needed this in the days when Diaspora dropped 1/3 of their messages into thin air to prove that it wasn't our bug and the post/comment was actually accepted successfully by the Diaspora side - before vanishing.
The reports also give you a hint whether or not your note was blocked, duplicated, delivered, stuck in the queue, or encountered some other error by a Hubzilla receiver. For other projects we can only tell you whether it's queued or accepted - at which point it's probably their fault. I don't know how we ever got by without it. You can tell an admin to read their logs, but you can't blame a casual user for wondering WTF? when their post/comment disappears or never arrives and with zero accountability. (I'm looking at *you* Mastodon).
-
Converted a large data center running 11/780s and 2BSD/3BSD to SunOS once SunOS4 came out. Earlier Suns crashed every twenty minutes and you couldn't use NFS with email because of the f*cked kernel locking code that took Sun over a decade to fix. I fixed it for our systems but Sun wasn't interested in the patches. We had some old multibus Sun1's that we turned into hardware routers. I didn't really care for SunOS and put a hacked BSD4.3 and later 4.4 on my sun2/sun3/sun4 desktops instead and spat the dummy when Sun officially dumped BSD and went with the SYSV nightmare "Solaris". Did some professional work on Solaris at Netscape but Sun was dead to me by then. The things I could tell you, but don't even get me started. #bsdstart
-
Currently I need to fetch somewhere between 10 and 25 URLs from a server to map out its protocol support matrix. This really should be in webfinger. We can drill down to get the details, but currently I have to drill down the various URLs for each protocol to even answer the question of whether or not it is supported. Maybe something like a webfinger property of rel=http://ostatus.org/federation-protocols which returns an array [ ostatus, activitypub, zot, diaspora, ... ] for each resource. Then we would know exactly what to look for rather than probing sites blind for a page full of possible federation urls and possibly pissing off fail2ban.
-
That's work in progress. Currently we negotiate the most capable protocol available and store/use that. Eventually I'll need to store the protocol capability array for every identity (I started on this about 3-4 months ago and got about 25% completed but got sidetracked). This turns out to be critical for making federated forums work.
-
I don't care if you use pseudonyms - and many people do. Internally we use a long cryptographic string for identity. Tagging a long cryptographic string is even less appealing to the average person than tagging some machine-derived identity string.
Both are wrong. We're tagging people, not machine codes.
In fact I start typing @+something and I get a dropdown and select the correct person by photo and name - the name I know them by. The correct link and name is added to the post. We do what we can to translate this to other networks but there is so much variation in how others do it that this is often wrong, and if they require signed posts we basically have to forge a different message for that network than the one we provide for our own. If that network engages in tag theft, we have to strip out the correct link and let them put in some (often wrong) local link (and name). Isn't federation wonderful?
-
We generally mention full names. Web handles are computer language, not human language. I'm "Mike Macgirvin" in Hubzilla. Why should I be some kind of artificial construct and attached to a server? Also with nomadic identity, it can get very confusing when several different handles on different servers can refer to the same person and the same identity.
-
Hashtag/mention linking is one of those federation problems that nobody can agree on. Diaspora links on receive and points the links to itself - a situation I call 'tag theft'. If you try to link these on send, the links will get buggered. Most other services link on send. Facebook and Twitter also link on receive iirc - just to ensure that you can't link to something that they don't control. So we accommodate either behaviour.
I've got a preference switch for Diaspora which links on send (preventing tag theft) and uses a look-alike Unicode character rather than the standard tag or mention characters so that Diaspora doesn't bugger the tags trying to steal them.
-
I don't know if the situation changed in the more recent releases, but in version 11, what was provided was ActivityStreams but *not* ActivityPub; though that is what was described in the official documentation. Somebody let the marketing department generate press without letting the technical folks proof-read it for accuracy. I looked at it early on to make sure I could federate it with Hubzilla and found that it was simply *not* ActivityPub and could not be coerced to federate with that protocol.
Statistics
- User ID
- 362210
- Member since
- 17 Jun 2017
- Notices
- 78
- Daily average
- 0
mike
All LoadAverage content and data are available under the