Who is technically writing the user stories?

The Scrum Guide does state that "clearly expressing Product Backlog items" is one of the responsibilities of the Product Owner. If you are using User Stories to capture Product Backlog items, then that responsibility does fall to the Product Owner. However, the Scrum Guide also goes on to state that the Product Owner may have the Development Team do some of the work around Product Backlog management, which includes expressing Product Backlog items, and that the Product Owner remains accountable even if some or all of the work around Product Backlog management is delegated to the Development Team.

This is probably a good discussion to have with the team, perhaps at a Sprint Retrospective. As someone new to the team, you can bring in your past experiences with things that have worked well or things that have not worked well to help elevate the team's practices and improve their way of working. I do think that you make a compelling argument, but the other members of the team do have their existing working agreements and styles, along with knowledge and experience (or lack of knowledge and experience in certain tasks). It's definitely worth a discussion, and bolstering the ability to clearly express Product Backlog items across the team may be something to look into, even if it remains your primary responsibility.

Now when I'm into refinement people look at me and tell me that PO is solely responsible of writting the user stories. 

You're together in refinement so you can collaborate. Why wouldn't you write the user stories jointly? Are you allowing enough time to do so?

As a part-time Product Owner in a startup, this is a question I've always wondered about, should I be writing more of the user stories?

We work in a very similar way to that which you have described in that we identify customer pain or opportunity, look at feedback from internal stakeholders and the strategic direction of the company and then make decisions about why features are valuable, what they should achieve and when they should be delivered.

I will add user stories if I'm confident that I know what stories are required to deliver a feature. Otherwise, the Development Team tell me to stop at the feature level in terms of breakdown and the Developers will write the user stories and tasks that are required to deliver the desired goal during the Sprint. Having the Development Team write users stories and tasks works for us because they deliver the stories and tasks during the Sprint. Maybe I'm just lucky as a PO or we've found an optimal way of working but it may not be optimal for everyone.

P.S - For context; yes, I know that a part-time Product Owner is not ideal, we have no Scrum Master, we have shared responsibility for that role between myself and the two Developers. I know we are doing something like Scrum but not Scrum according to the Scrum Guide, for many reasons, one of which is our budget limitation in that we can't put the optimal team size and people with full-time roles into the team. It helps that both the developers in our company are experienced using Scrum.

@Ian Mitchell, Could it be that the reason for this question stems from, should the PO be the "only" one writing stories as the PO is accountable, responsible for the backlog as per the guide or should the BSA on the Dev Team be the "only" one(s) writing the stories?

In my opinion, anyone who has the knowledge to write the story and its intended functionality and acceptance criteria should write it. It could be the PO, or any member of the Development Team (this could be BSA, Tester, Developer etc)

A question that may arise is should a Developer write a story, and my answer is sure, why not? Sometimes, isn't it possible that we need to add items related to technical debt, which may be something that the Development Team needs to address or the Development Team realizes that they need to do more work than anticipated. In such scenarios I don't see anything wrong with a Developer or a Tester or a BSA writing stories and keeping the PO informed.

Note: I've used terms like Developer, Tester, BSA even though the guide only says Developer because in reality we do tend to address people within the Development Team with such titles.

Why wouldn't you write the user stories jointly?

I would always discuss them together. The writing itself I see by the developers. I believe when the developers are finalizing the story (the input of the story (pain) and priorization is of course always POs responsibilty) they are taking more responsibility and engangement in the product. They are finishing the User Stories in their own words and getting a better understanding of the product. Which leads to less questions during the sprint.

It's like when I'm going to the client and asking of his pain points, I'm writing them down in my language and them I understand them better after some days.  

Besides, I made the experience the more solutions I provide, the less the product becomes a team product and commitment goes down. 

Are you allowing enough time to do so?

Good point: For me we have the 10% sprint time for refinement, which we so far have never exceeded. But in the past refinement was done 1 time per week 2h max. Now we are having 3-4 days per week ca. 1 hour refinements  and the developers are "clomplaining" like "Refinement today, once again?"

I usually suggest that the Product Owner start the PBI by stating the user facing problem that is needs to be addressed. That gives the Development Team insight into why the PBI exists. If the PBI is purely technical related (such as upgrading a component) the Development Team is better positioned to provide the necessary details. After that when the team is refining the story, additional details are added by someone. Who really doesn't matter as long as the refinement is captured in the PBI. 

Who is technically writing the user stories?

Technically the Scrum Team because they all contribute to refinement. 

I made the experience the more solutions I provide, the less the product becomes a team product and commitment goes down. 

One sided solutioning does carry that risk. Hence it is important for team members to collaborate as much as possible and to take every opportunity to do so.

On the basis of what you provided  I conlcuded two things: 

1. Our current situation, that I'm writing all User Story completly is not ideal and could be inmproved

2. The person who is most suitable to write/ finish the story should write it. 

(3.) Our curent biggest pain point is not who that developers dont want to finish the User Stories

-> I gonna start writing story and finish them during refinement. When there is a point which it makes more sense that a developer or some other person could finish the story I gonna ask if it wouldn't be more productive if he or she could take over.

Thanks for your support

2. The person who is most suitable to write/ finish the story should write it. 

If you mean start writing and finish writing the story I can agree with that.  But be very careful that this doesn't become where the person that does all the work should write the story.  That can lead to behavior that is adverse. It will usually lead to each person writing a story for something that they want to do and it may/may not be tied to an actual product goal.