This is an example of a marketplace listing in Flohmarkt.
What "I" did here...
Went to the "All" tab over at Flen's Market - Much like PeerTube, there's a Home, Local, and All tab, the latter of which includes items from other instances that you've manually federated with within the radius you've specified from your location.
Next, there's a choice to make if you're interested in an item. You can register for a local account (I don't see any reason to do that unless you want to post a listing on that particular server), or you can remotely add yourself (like I did). Since the remote features don't quite seamlessly work with Mitra, I tried this from a masto server - no joy. I tried it from another masto server (a masto fork) - no problem this time, even on an older version of masto. That was humorous to me, as I've a bit of disdain for mastopub servers and found it amusing that even some of the instances running the very latest version of masto won't work, while older one's based on forks do; but I've got a twisted sense of humor.
So next, you can engage with the seller directly from your local instance on most Fediverse platforms (support is added for various additional Fediverse platforms all the time). In this case, (visible because I chose the "All" tab), the particular item was from yet another #Fohmarkt server elsewhere - this is a very nice feature, like #DeSoc#eBay!!!
From there, once you boost the item in the listing, others can see it in their streams, boost it further, make arrangements directly with the seller, etc. Kinda Kewl.
This is different from how most other attempts to deliver a marketplace into the #Fediverse. Usually, what I've seen is someone trying to integrate the functionality local to a platform, which networks (via ActivityPub federation) only with other like platforms. That's not a Fediverse solution - that's a platform solution and leaves everyone else on the fediverse not running that particular platform disenfranchised.
For example, using the Epicyon server platform as an example, it is first to be understood that this particular server platform is designed for very small numbers of user accounts per each instance. You also have to manually contact the admin of remote Epicyon servers yourself (or be contacted by them), then mutually agree to federate each other's marketplaces separately and distinct from any wider federation configurations your server has. Considering the inconveniences with locating other Epicyon instances that may or may not have enabled and made use of their marketplaces and establishing a mutual publishing agreement, coupled with the likelihood that each of your instances between 1 and 10 users, posting an item in the marketplace has a pretty high probability of being more effort than its worth - especially since it dosn't federate with any other Fediverse platforms.
Others follow a similar design, but also generally operate like normal #ActivityPub federation using a blacklist method, as well as being able to accommodate potentially hundreds, or even thousands of users per each instance (yeah, I know, semi-monolithic); so even if those marketplaces didn't already automatically federate across the Fediverse with all instances of other like server platforms, it's still a huge improvement over the previously discussed smolweb platform's model.
But they're still not Fediverse wide...
This is where Flohmarkt really starts to shine - it's fully Federating (Still a WIP wrt some platforms - see the wiki for particulars) across the entire #ActivityPub portion of the Fediverse.
You can check for the latest particulars on Flohmarkt's current Federation status if you're interested in your particular Fediverse platform and level of interoperation with Flohmarkt instances.
I do have some criticisms of the particular functionality in federating that the developers have chosen to incorporate, however. Basically, The server admin still needs to manually federate item listings between the local instance and other remote Flohmarkt servers. It doesn't need to be this way however, but one must concede that after going over the documentation and seeing that the concern's of the dev team are over unchecked spam, phishing, poor quality ads, etc., I find it to be a very reasonable concern, although I'm still not comfortable with how the Dev team has hard-coded this conditional into the server's capability, when a slightly different approach might afford self-hosters much greater flexibility and incintive for adoption; namely:
Make the current model the default
Enable other configurations for federating between other Flohmarkt servers (and eventually, other platform marketplaces) via either simple configuration files, runtime arguments, or via a GUI in an admin control panel, including that of an uninhibited fully blacklist model of sharing listings between Flohmarkt servers.
I generally tend to think that hard-wired, opinionated configuration choices are a less than ideal (usually bad idea) than acknowledging issues surrounding such decisions and then choosing a default while affording server admins (or users themselves) of being able to manage the options for themselves. This is one of those cases where I feel it could make a huge difference in the viabilty and adoption potential for this, "Strictly Federating Marketplace" Fediverse platform.
The other (very minor) criticism I have for Flohmarkt is the pin & string radius solution as it is currently implemented:
It's determined by the server admin, instance wide
It's determined by the server location, or some other arbitrarily decided locale
The radius is a great idea, but I think the following would go a long way towards improving the utility of this feature set:
The server admin decides whether to enable user-level radius configs or server level, as is the case at this time.
Local users determine, and have control over whether an established is applied to either their entire user profile's repertoire of items listed, or on a per item basis.
If he user chooses a per item radius, each listing could have a different radius established.
The local users have location radius specifications that can be based on different criteria, such as pinning a location on a map of their choice, by country (the free IP2Location databases can accommodate this behavior).
The user's particular radius settings for each listing must be preserved and observed by all federating remote Flohmarkt server instances (but not by individual remote user shares/boosts, which should remain unrestricted).
This Radius feature is extremely powerful and I think that every effort of the development team to exploit the potential of this feature set should be a major consideration. Eventually, Flohmarkt servers will federate with other server platform types, exchanging listings between say, Flohmarkt servers and Friendica servers, etc.. but the awesome power unleashed through following and boosting capabilities that are already fully available to remote users to share with others holds the potential at this very time to make Flohmarkt item listings ubiquitous across the entire Fediverse, ... And that is really kewl :)
Well, I'd rather tease your interest and see you go checkout more for yourself rather than feed you everything you wanna know about a really kewl #social_commerce communications tool - you really should experience how kewl it is for yourself.
I couldn't locate a #Matrix support room for Flohmarkt like most contemporary software products maintain in the FOSS world, but the more traditional irc chan #flohmarkt at #LiberaChat is readily available, and of course, there's the issue tracker at the Codeberg repo I previously linked to above.
What are your thoughts and impressions on this novel approach to embedding the marketplace commerce structure into potentially everyone's social streams in the form of both a dedicated platform and as passive feeds via the intervention of other #Fedizens who share and boost individual items and listings in Flohmarkt?
Ghost is an excellent platform for publishing. I used it a lot a few years back for publishing articles when it was headless - that was optimum. Compose at your leisure within your own local environment, then push it up to your own self-hosted instance.
Unfortunately, they let it fall into disrepair, left it unmaintained, and last I checked the Ghost desktop was nowhere to be found in the repo. One of the maintainers explained to me that they just didn't have anyone willing to maintain the app and so I migrated away from the platform myself.
I'm going to give it another looksee to review what happened to the elegant, #headless nature that Ghost used to espouse as one of it's key ingredients for using it in the first place. I just hope that they don't try to go the way of #OOo, #Bacula, and other #FOSS projects that were forked, and somewhat marginalized, as a result of decisions to force community versions into #Freemium products that lacked most functionality without fee based subscriptions. Lord knows, the last time I checked their managed hosting solutions for Ghost it certainly wasn't even competitively priced.
With this newfound revelation in the form of some kind of epiphany, let's hope their commitment to #Fediverse and FOSS exceeds that of their grasp for excessive monetization.
Be sure to check the Link below in the link that @jeze left and sign up!
Pretty kewl, IMO. Thanks for sharing Elley :) it looks really nice and I created an account for myself. Seamless federation with the others too - very nice :)
@tallship
It's a retro digital mode being a binary format. Like today's digital modes CW gets through the noise floor when voice can't be made out clearly...
So Ryan, thank you for this most valuable tool to bring people around the globe together in #DeSoc - creating (and curating, as you have) ***Bridgy_Fed is one of the very best things that the Fediverse has to offer people on both sides of the protocol divide, and I really don't think that there are enough Thank you's to go around for all of the selfless effort you've put into this service.
So as meek and perhaps insignificant as it may sound, THANK YOU!
Content from Socialhome boosted or quote-posted in Hubzilla looks really nice and the inline media of articles is preserved as presented in the original post as well - very nice!
But what about those #MS_Windows users out there? How about a gzipped tarball, all nicely packaged up so you can distribute around, of a custom built #PuTTY client that will securely connect people to your #Synchronet_BBS over telnet?
Hehehe.... I suppose this is my opportunity to plug Joshua's free domain name service here that's been a trusted mainstay for over 20 years :p
Perhaps one of the best parts is that you can see how many days (years) the domain has been part of the service, to dissuade concerns over whether there's a likelihood of it suddenly disappearing :)
Aside from lotech #Sneakernet schemas, there's also several FOSS based community driven initiatives. There's been a lot of real-world, ad-hoc development since my years of participation in the IRTF/IRSG DTNRG. Full disclosure, I was also formerly employed by Semtech. The notion that there's a use case for communications that can take months, even decades to arrive (or never at all) is a valid concern for many practical applications.
More immediate, and relevant communications systems for most folks here on Terra Firma include projects like Lokinet, which has some great info HERE, and also aspires to the same level of, um... disconnectivity (sneakernet-like) or operability that @silverpill mentions above - the value of having a client/server architecture that is prepared to exploit this out of the box is much relevant that one might think.
Some of these semi-production or production ready real world initiatives and communities are:
CellSol - It is noteworthy to mention that Texas is the only state in the USA that sports an (actually only mostly) autonomous electricity grid (not dependent upon the national grid), although it's not publicly managed, and has been criticized as such due in part to nearly 1000 deaths occurring in the winter of 2021. The repo is HERE. Here's a PoC for one such use case from the PoV of a native Texan: Apologies for directly linking to an article in the monolithic silo space.
During my years living quite literally off-grid in the wilderness of the forested mountains in Northern California, I had the privilege of meeting and contracting for several farms and individuals deeply steeped in what is generally referred to as the prepper movement. These weren't cray cay militants (at least not most of them) or paranoiacs calling for revolution or believing the end is nigh, but rather, farmers and families who were, rightfully so, extremely concerned with security and safety for their small communities and loved ones. To survive in places like that, which exist all over the world, one must begin with self-sufficiency that covers 4 seasons; beyond that, protecting the 'me and mine' aspects of your assets and property are very real considerations.
The work I focused on led me to developing microwave surveillance systems using inexpensive, solar powered Ubiquiti Nanostations with ranges capable of exceeding 10KM, strategically placed in almost inaccessible locations overlooking entire valleys as well as within small perimeters of their farms and households. This included off the shelf PTZ cameras, many of which were capable of license plate and facial recognition, but more importantly, being able to determine the difference between things like Bears, Deer, and Humans - false positive intrusions detected are quite frustrating, lolz.
All of this was coupled together with Shinobi, which can be monitored and controlled from anywhere, on any device. The repo is here.
With the extreme threat levels of thievery and other concerns in those regions, and continuous incidents of such, a comprehensive #FOSS based, #solar powered communications and surveillance system is an in demand market. Internet access is of course, problematic in such regions, which creates the market for WISPs operating in the unlicensed microwave bands a high demand commodity as well.
This is merely demonstrative of the need for another niche type computing arena - community networks completely unconnected to the Internet:
All of these projects, protocols, and initiatives have solution based choices for the various kinds of Delay Tolerant Networking standards and communities actively developing for connectionless, intermittently connected systems, or autonomous networks that aren't neccessarily interdependant upon a classic, traditional, Internet connection.
Not sufficient to just eschew the deprecated, privacy disrespecting monolithic silos, it's also not prudent to depend upon clearnet aspects of the Internet either. In practice, it's possible to take pretty much any platform technology that listens for packets and fashion the ability to be accessible and available via I2P, Tor, IPFS Yggdrasil, and other IP routed constructs, yet moreover, the majority of people only consider intercommunication in terms of the IP routed packet switched network we call the Internet (powered almost entirely by Cisco IOS and the like), without due consideration given to the fact that this single common denominator is also a single choke point - kludgy platforms like masto that can't even keep up with the contemporary movements in the social networking landscape aren't going to fare well when it comes to the expanding horizons opening up with movements like those above, while others like Sreams, Mitra, and perhaps protocols such as Nostr that exhibit the ambitions to explore and exploit emerging technologies in communication will fare much better, adapting (and embracing layer 1 & 2 networking) along the way.
More great news on the #rPi front - remote access for #SOHO and Home based networks as simple as a single apt install command!
Give it a try today and let us all know what you think! I'm interested in hearing your thoughts and experiences with this invaluable remote access tool.
#e2ee is a goal, not a promise. As far back as I can remember, forums like those supporting #Enigmail and #gpg were staffed with volunteers from the privacy community who repeatedly insisted on answering questions, like, "Is <this> (whatever this might be) totally secure?" with stock questions like, "What is it that you consider 'totally secure?" or answers such as, "Secure is a relative term, nothing is completely secure, how secure do you need your mission's communications to be?"
Phrases such as, reasonably secure should be indicators of how ridiculous it is to assume that any secure platform isEVERcompletely, and totally secure.
That begs the question, "Exactly how secure do you require your communications to be?" The answer is always, ... relative.
Which means that you should always believe Ellen Ripley when she says, "Be afraid. Be very afraid!"
My experience is that state actors won't even try to decrypt your communications. That's old school - and a horribly inefficient use of resources. They'll come after you with a keylogger or manufactured legal nightmares or torture - to either or both sides of the communication; depending on the perceived value of your secret.
It all comes down to 4 fundamental questions:
What is the value of your secret to you
What resources do you have available to protect it
What is the perceived value of your secret to your adversary
What resources do they have available to divulge it
I'm unable to pull this up and boost here. Was able to get the whole stream on a Glitch-soc box np, and I can follow the curator here too, but I'm too tired to try testing on Hubzilla or Friendica at the moment; so I'll just post the link then, which may be of interest to some, ... Actually, I suspect, many.
We've had some discussions about this over in the Fediverse-City Matrix room, Where Ryan is also a participant. It's apropos of the recent onboarding with respect to Flipboard curators and also the nacent interoperability we're experiencing with Bluesky's ATP.
After several years of warning after warning after advisory after advisory and calls to repeatedly update or remove andNOT USE CHROME by the Department of Homeland Security, it should be inconceivable that anyone does - but they do.
Sometimes these are patched with automatic updates before horrific and catastrophic results occur, sometimes not. To be frank, part of the problem stems from the fact that Chrome is the largest attack surface out there where browsers are concerned, but notwithstanding it being the fav target are also serious privacy concerns that aren't shared by other chromium based browsers.
To be fair, many exploits are indeed shared by other chromium based browsers, but not most, while some are related to other browser capabilities, like WebRTC, but it's still best to just ditch Chrome and never look back.
Here's more coverage on vulnerabilities issued less than a month ago. It took 3 seconds to bring this up, and no, not using Google, which didn't reveal this when I tried that search engine in a subsequent search, lolz. Why would they return SERPs that poo poo their own product?
There's truly only one way to ensure safety - unplug. But there's a lot of simple things you can do to exact a reasonable level of security, so why not observe some of those best practices? It's not like it will cramp your style.
Anyway, that's my two cents. h/t to @darnell for raising awareness of this latest brokewell. Make sure you take the time to visit the link he's provided for you too.
There are plenty of #Browsers that run on #Android (to name a few, alphabetized):
Brave Browser
Chromium
DuckDuckGo
Firefox
Kiwi
Vivaldi
IMO, No one should be running Chrome - Desktop or otherwise. It's a privacy nightmare even when there aren't CERT warnings circulating.
Okay it's one of those, "What's peculiar here?" kinda things.
Consider the source itself. And I certainly don't mean code of any sort. 'Why' would 'They' cite Wikipedia, as good a resource as anyone might think it to be?
Why not cite yourself? Instead of citing someone else - who will merely turn right around and cite you as the ultimate source reference?