Simpler alternatives?

1

This may not be the best place to have this discussion, but over the last week I’ve been having second thoughts about using Solid for my application. Please feel free to change my mind :slight_smile:

I’m onboard with the general idea, but my main concern is that it’s being over-complicated. I have a habit of over-complicating things myself, and so I often need to take a break from what i’m doing and ask myself how I can make it simpler. After all, my initial objective is to provide people with a free CV, and do so ASAP, as there will be lots of people out of work as a consequence of the current pandemic.

Anyway, I’ve been trying to come up with the simplest way of achieving my objectives by leveraging the technologies that already exist.

To start with, I’ve completely redesigned my app, which you can see here. This version doesn’t use Solid, but instead gets the data from an XML file, which you can see here.

EDIT: Unlike the app that I posted before, the users will download and upload the files wherever they choose.

For this to work, the host will need to be CORS enabled. My assumption is that most hosting providers won’t enable CORS by default. However, as far as I know, I can enable CORS using a htaccess file. Is that true?

Users will need to pay for hosting, a domain name, or both. Let’s face it, asking users to pay for something could be a deal breaker. However, until I can find a better solution, that’s just what they will have to do. BTW, how were the Solid team planning to get around this problem? Someone’s got to get paid right?

The next step would be to allow users to write to their profile.xml file. I guess i’ll use PHP for the login. I will ask users to login via a browser extension. Any app can read data from the users’ datastore, but write operations will be routed through the extension. For example, if a user wants to post something on a different app, a message is sent to the extension and a popup will appear asking the user to confirm the action.

As far as i know, only a handful of mobile browsers support extensions. I suppose all I can do is ask users to use a browser that supports extensions. It’s not ideal, I know.

Each profile will have a “subscribe” button, where you can subscribe to their posts (something which I will implement at a later date), and their posts will show up in the NEWS tab.

I will continue to roll out more features (and “ontologies”) over time, but that’s the basic idea.

So, do you think this is feasible?
What obstacles will I need to overcome (other than the ones I’ve mentioned)?
Should I just stick with Solid? If so, why?

Any comments/advice would be greatly appreciated.

1 Like
2

For starters, once again my compliments on the look and feel of this thing.

I share the Solid vision, but also your doubts on the initiative. I’ve spent a lot of time discussing scope and positioning of the solid project, most recently in this thread. The complexity is one thing, but it comes with the feeling that solid project is working all over the vast scope of the initiative and therefore it’ll take years for things to reach maturity and production-readiness.

My interest is in combining the best of both worlds of the ActivityPub Fediverse - which is linked data-based and does have a whole bunch of production-ready, widely used applications already - with Solid’s strength: full control of the data you expose (see also: How Solid and ActivityPub complement each other best).

But I find it hard to lay my finger on just this core feature, Solid’s main USP (ostensibly). From that perspective I intuitively am more attracted to Encrypted Data Vaults with its layered and modular architecture.

But things can change and improve, and that’s why I’m here :slight_smile:

So I see a benefit and opportunity for your application to be both Solid in terms of data storage and well-connected, accessible in terms of ActivityPub support. There has been a project called CloutStream (now dead) that was intended to be the LinkedIn for the Fediverse (and could also be part of the IndieWeb at the same time). I’ve seen many people state the desire to restart this or a similar project. This will be a popular project I predict.

(I’ve been thinking to doing something like that too (after finding react-resume), but my current hobby project is innercircles.)

Anyway, the fediverse offers the social features you want (subscribe, follow, interact), and the ability to federate, set up your own instance, or choose an existing one to host your account / blog / CV. There are a lot of personal blogging softwares in the making, and adding a CV to this concept would be a natural fit.

I would not continue the XML path. I’ve been deeply involved in XML dev for a number of years, but right now it is mostly used in enterprise contexts and elsewhere we have JSON et al.

Regarding offering your CV functionality… this seems a complicated path. If you develop the core functionality as a JS library, then integration in various platform (e.g. wordpress) becomes easy (and can be done by others too). Additionally you can have a server software that can be self-hosted and for which you have your own instance to which people can subscribe. You can then either allow [username].my-cool-domain.name (requiring DNS admin on your site, or cPanel / whatever automation) or just my-cool-domain.name/[username]

1 Like
3

OK thanks for the info :wink: I briefly looked into ActivityPub in the past. I don’t remember the exact reasons but I decided that it wasn’t suitable. I’ll do some more research though, as maybe there were some things which I didn’t understand.

The thing is, I want users to have as much control over their data as possible. What i’m suggesting is that each user has an XML file, which they can store on any CORS enabled host. And the reason I chose XML as opposed to JSON, is because it’s easier for the average person to read and edit directly. Separating the data from the applications that use it is a core part of the Solid ethos, yet there is no way I could ask my users to edit a ttl file. The only complication is updating the XML file via the browser extension, but I think it can be done.

Anyway, when I get the chance I’ll spend more time looking into ActivityPub. However, I want to publish something which people can benefit from asap, and so if I think it is going to be too much hassle, then i’ll stick with what I’ve got :slight_smile:

4

The problem, but also the beauty of, ActivityPub is that the standard leaves a lot of things undescribed. This allows flexibility and stuff for other standards to fill in, but also leaves a bunch of things open for interpretation to the implementer. But it is the reason why ActivityPub has picked up steam relatively quickly in production-ready projects…

If you have any questions about AP you can ask on SocialHub or Feneas.

In my opinion a well-designed JSON is equally or easy to edit. Or should I say hard… because it is not something you want to offer to people to maintain their CV. A simple online form, and maybe some import/export feature would bring that to the masses. Fully agree on turtle editing, this is geek-only stuff. Problem in many solid PoC projects I see is that the UI’s are so technical, that they’ll only appeal to someone deeply involved in the initiative.

Regarding getting something up quickly, there is no problem with AP. You can start with just your web-based UI and add federation support later (there is no need to implement client-to-server AP interface). And this you can achieve by cloning code from some existing project. The watchlist link above gives a good overview of what is around to start from.

1 Like
5

OK thanks again. I’ll take a deeper dive into ActivityPub then. If I can implement it incrementally and ensure that users have ownership and control of their data then I think that would be the best way to go :wink:

1 Like
6

Why don’t build a profile editor app to help the user to edit his file ?

7

The CV will be just a few files. The user will download the CV, and install it wherever they choose. If they want to use an editor which I (or someone else) builds, they can. But In order for the data to be truly decoupled from the applications, I would like to use a format which they can edit directly.